Question about math.pi is mutable

[BartC]

On 10/11/2015 11:34, Steven D'Aprano wrote:
> On Tue, 10 Nov 2015 05:10 pm, Ben Finney wrote:
>

>> I am a Bear of Little Brain, but: Isn't anything that the *compiler*
>> does, by definition done at *compile* time?
>
> In a manner of speaking, yes, of course. But you've missed the critical
> issue: when is compile time?
>
> If you're like most people, you probably are thinking about an execution
> model where the compiler analyses the source code statically, using nothing
> but what can be seen in the source code, then hands over some sort of
> compiled byte code to be run by an interpreter or machine code that is
> executed by the CPU. The compiler and interpreter are completely distinct.

Does the Python language specify how it is to be compiled and executed?

If not, then you can use any interpretation you like, provided the 
program gives the expected results.

That includes using a static compilation pass that generates byte-code, 
even if it is only done immediately before running the main module, or 
just before performing an import operation on another.

> If so, you're stuck with an obsolete model of computation, like somebody
> trying to understand modern chemistry based on the "planetary orbit" model
> of the atom.
>
> So when is compile time? Of course, in some languages (like C, or Pascal)
> compilation occurs as a distinct stage before you can run the code. But
> that's not necessarily true for all compilers.

C can also be interpreted from source as you go along, although it can 
be very difficult (but probably not as difficult as implementing PyPy).

Anything is possible. But the chances are that if you are running 
CPython, then it will probably include a discrete byte-code compiler.

> execute
> this Python snippet:
>
> result = x + 2
>
> At static compile time, looking just at the source, you may not know what
> value x is, or even whether or not x actually exists, so you're forced to
> go through the standard Python semantics to determine what the result is:
>
> py> from dis import dis
> py> dis("result = x + 1")
>    1           0 LOAD_NAME                0 (x)
>                3 LOAD_CONST               0 (1)
>                6 BINARY_ADD
>                7 STORE_NAME               1 (result)
>               10 LOAD_CONST               1 (None)
>               13 RETURN_VALUE
>
>
> But a JIT compiler gets to compile code right before that line is due to
> execute. By the time the JIT compiler gets to see that line of code, it can
> already know whether or not name "x" exists, and if so, which namespace it
> is in. It knows what value "x" has.

How does it do that? How is the 'x+1' even stored in the machine? 
Suppose the preceding lines are:

    if random+bit()==1:
       x=920.5
    else:
       x=[8,5,4,9,1,7,6,3,2]

or:

    if some_condition: del x

it will probably know as much about x as the static compiler does! And a 
static compiler can still do a surprising bit of analysis, such as 
transforming the the first if-statement above, followed by your return 
statement, into:

    if random_bit()==1:
       return 922.5
    else:
       raise_error()

But we're trying to find ways of avoiding a dictionary lookup, ie a 
LOAD_GLOBAL or LOAD_NAME. If static analysis of the entire source can 
yield fixed tables of such names as 'x', even if subject to runtime 
alterations, then why not do that if it means possible faster access.

> More about JIT compilation on Wikipedia:
>
> https://en.wikipedia.org/wiki/Just-in-time_compilation

JIT covers a lot including straightforward translation of byte-code for 
a statically language, into native code.

In a language like Python, it's rather more elaborate.

And PyPy, as you hinted, is complelely different. I don't think it even 
attempts to JIT compile your example, it JIT compiles some repeatedly 
executed pathways in a program some way removed from the Python code or 
even its interpreter.

Or something like that... Whatever it is, it's more like magic. But what 
I started discussing here are ways of making a regular Python 
interpreter more efficient. I think that with projects such as PyPy, 
people are less interested with speeding up CPython, for one thing 
because it is not going to speed things up by ten times, so there seems 
little point.

-- 
BartC