summaryrefslogtreecommitdiffstatshomepage
path: root/docs/esp32/tutorial
diff options
context:
space:
mode:
authorDamien George <damien@micropython.org>2023-05-03 13:21:18 +1000
committerDamien George <damien@micropython.org>2023-05-03 13:21:18 +1000
commit1b980c9dbef33edcddd7b7cf8533fb8b0bbb1aec (patch)
tree0b99b1027412e4ff6fe5a5f5b3af8987f8cced14 /docs/esp32/tutorial
parent957bd5118477df89e0539bc2c5325810059b6ad0 (diff)
downloadmicropython-1b980c9dbef33edcddd7b7cf8533fb8b0bbb1aec.tar.gz
micropython-1b980c9dbef33edcddd7b7cf8533fb8b0bbb1aec.zip
py/compile: Remove over-eager optimisation of tuples as if condition.
When a tuple is the condition of an if statement, it's only possible to optimise that tuple away when it is a constant tuple (ie all its elements are constants), because if it's not constant then the elements must be evaluated in case they have side effects (even though the resulting tuple will always be "true"). The code before this change handled the empty tuple OK (because it doesn't need to be evaluated), but it discarded non-empty tuples without evaluating them, which is incorrect behaviour (as show by the updated test). This optimisation is anyway rarely applied because it's not common Python coding practice to write things like `if (): ...` and `if (1, 2): ...`, so removing this optimisation completely won't affect much code, if any. Furthermore, when MICROPY_COMP_CONST_TUPLE is enabled, constant tuples are already optimised by the parser, so expression with constant tuples like `if (): ...` and `if (1, 2): ...` will continue to be optimised properly (and so when this option is enabled the code that's deleted in this commit is actually unreachable when the if condition is a constant tuple). Signed-off-by: Damien George <damien@micropython.org>
Diffstat (limited to 'docs/esp32/tutorial')
0 files changed, 0 insertions, 0 deletions