Le mercredi 18 mai 2011 à 21:44 -0400, Terry Reedy a écrit :
> On 5/18/2011 5:34 PM, Victor Stinner wrote:
>
> You initial example gave me the impression that the issue has something
> to do with join in particular, or even comprehensions in particular. It
> is really about for loops.
>
> >>> dis('for x in range(3): y = x*x')
> ...
> >> 13 FOR_ITER 16 (to 32)
> 16 STORE_NAME 1 (x)
> 19 LOAD_NAME 1 (x)
> 22 LOAD_NAME 1 (x)
> 25 BINARY_MULTIPLY
> 26 STORE_NAME 2 (y)
> ...
Yeah, "STORE_NAME; LOAD_NAME; LOAD_NAME" can be replaced by a single
opcode: DUP_TOP. But the user expects x to be defined outside the loop:
>>> for x in range(3): y = x*x
...
>>> x
2
Well, it is possible to detect if x is used or not after the loop, but
it is a little more complex to optimize than list
comprehension/generator :-)
> .. you cannot get that with Python code without a much smarter optimizer.
Yes, I would like to write a smarter optimizer. But I first asked if it
would accepted to avoid the temporary loop variable because it changes
the Python language: the user can expect a loop variable using
introspection or a debugger. That's why I suggested to only enable the
optimization if Python is running in optimized mode (python -O or python
-OO).
Victor
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
