[Tutor] <var:data> value changes

[Danny Yoo]

On Thu, 13 May 2004, denis wrote:


> Now, let's (try and) check this does not with out-of-range (sic!)
> values:
>
> >>> x=100; y=100 ; x is y
> True
> >>> x=1000; y=1000 ; x is y
> True
>
> What's up ? (I've really been surprised!) A more careful trial:

Hi Denis,

[Note: really obscure CPython optimization discussion; do we really want
to talk about this?  *grin*]


It's an optimization based on what Python is doing during interactive
interpretation.  It actually does have a little bit to do with the
multiple statements that you're doing, but it's more general than that:

###
>>> while True:
...     x = 1000
...     y = 1000
...     break
...
>>> x is y
True
###


Notice that we're getting a different result from your previous
experiment:


> >>> x=1000
> >>> y=1000
> >>> x is y
> False


When we run Python as an interactive interpreter, Python first does a
byte-code compilation pass over the things we are typing, and then
executes that bytecode.  That is, when we're doing:


###
>>> x=1000
>>> y=1000
>>> x is y
False
###


behind each statement is a mini-compile step going on.  That's what the
'>>>' is saying: that the Python interpreter is ready to compile and
execute another statement.  Since each statement is compiled and executed
separately, Python won't even try to do any global analysis: it won't try
to see that x and y are directed at the same constant '1000'.  The scope
of optimization is the "block" of code that the byte-compiler sees.




On the other hand, when we send the interactive interpreter something
like:

###
>>> while True:
###

Python can't immediately byte-compile this: it must see the whole while
block through and through, before doing anything else.  And that's why it
prompts us for more information, with the '...' prompt:

###
>>> while True:
...     x = 1000
...     y = 1000
...     break
...
>>> x is y
True
###

So the byte-compiler is fed the whole 'while' loop.  Since it can see the
whole block as one unit, all at once, it has a bit more room to infer that
'x' and 'y' are the same thing, and can set them to the same constant
object '1000'.



> This difference of result shows that two 'equivalent' syntactic forms
> aren't processed the same way.


It has less to do with syntax, more to do with the way the interactive
interpreter is working.  If we were to run Python on a file, then we'd see
that the byte-code compiler is able to analyze the whole module file, as
Bob Gailer mentions.


All of this discussion, though, is on a really obscure optimization that
isn't advertised Python behavior.  It works only on constant "immutable"
values because it doesn't change Python's observable behavior.  All the
optimzations that Python does, behind the scenes, are supposed to be
practically invisible to us.