Question about math.pi is mutable

[Terry Reedy]

On 11/9/2015 9:37 PM, Steven D'Aprano wrote:

> The compiler doesn't need to decide *in advance* whether the attribute might
> have changed. It knows whether it has changed or not *at runtime*.

You are using 'compiler' when you should, to avoid confusion, use 
'interpreter'.

> It's one thing to say that *in principle* any function might modify or
> shadow builtins. That's true, because we don't know what's inside the
> function. But the compiler knows, because it actually executes the code

'interpreter'

> inside the function and can see what happens when it does. It doesn't have
> to predict in advance whether or not calling `func(x)` shadows the builtin
> `len` function, *it can see for itself* whether it did or not.
>
> At compile time, `func(x)` might do anything. But at runtime, we know
> exactly what it did, because it just did it.
>
> Imagine that the compiler keeps track of whether or not builtins has been

/compiler/code compiled by the compiler and interpreted by the 
interpreter (which could be the CPU)/

> modified. Think of it as a simple "dirty" flag that says "yes, builtins is
> still pristine" or "no, something may have shadowed or modified the
> builtins". That's fairly straight-forward: builtins is a dict, and the
> compiler can tell whether or not __setitem__ etc has been called on that
> dict. Likewise, it can keep track of whether or not a global has been
> created that shadows builtins: some of that can be done statically, at
> compile-time, but most of it needs to be done dynamically, at runtime.

This is more or less Victor Stinner's proposal, and he has a working 
prototype that runs nearly all the test suite.  He now plans to refine 
it and measure changes in space and time usage.

> If the flag is set, the compiler knows that the optimization is unsafe and
> it has to follow the standard name lookup, and you lose nothing: the
> standard Python semantics are still followed. But if the flag is clear, the
> compiler knows that nothing has shadowed or modified builtins, and a whole
> class of optimizations are safe. It can replace a call to (say) len(x) with
> a fast jump, avoiding an unnecessary name lookup in globals, and another
> unnecessary name lookup in builtins. Or it might even inline the call to
> len. Since *most* code doesn't play tricks with builtins, the overhead of
> tracking these changes pays off *most* of the time -- and when it doesn't,
> the penalty is very small.


-- 
Terry Jan Reedy