Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Terry Reedy <tjreedy@udel.edu>
Newsgroups: comp.lang.python
Subject: Re: Question about math.pi is mutable
Date: Tue, 10 Nov 2015 03:30:05 -0500
Lines: 53
Message-ID: <mailman.200.1447144233.16136.python-list@python.org>
References: <n1kshk$brb$1@dont-email.me> <n1l3kd$5ma$1@dont-email.me> <563eba85$0$1611$c3e8da3$5496439d@news.astraweb.com> <n1n8mc$33l$1@dont-email.me> <87ziyowy83.fsf@elektro.pacujo.net> <n1nb0f$atn$1@dont-email.me> <mailman.135.1446998410.16136.python-list@python.org> <n1o25a$3s3$1@dont-email.me> <mailman.142.1447005691.16136.python-list@python.org> <n1o5sl$joc$1@dont-email.me> <mailman.152.1447024427.16136.python-list@python.org> <n1on71$san$1@dont-email.me> <8537wghwjb.fsf@benfinney.id.au> <CAPTjJmo=4p3DnvcLY_whdzaiy1t-sTyok20U9M0nQsNCg9_E=Q@mail.gmail.com> <85y4e8ggrj.fsf@benfinney.id.au> <CAPTjJmqaTQy397xgSjQsC2Bu8mxDQTvGsryp0e6nDk6Le688=A@mail.gmail.com> <85twowgfm6.fsf@benfinney.id.au> <CAPTjJmq--XE006MzxNe_3d_rmOP9GYxM_AxMF7Nh3d3RQbBx4g@mail.gmail.com> <mailman.160.1447031104.16136.python-list@python.org> <564081e7$0$1592$c3e8da3$5496439d@news.astraweb.com> <mailman.186.1447098364.16136.python-list@python.org> <56415873$0$1614$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <56415873$0$1614$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:98580

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