[GvR]
> Hi Raymond. Too bad you couldn't make it to the conference! We're
> all having a great time on and off the GWU premises.
Glad you guys are having a great time. I wish I could be there.
> I used your "more zen" on a slide in my keynote.
Cool. Any chance of getting your keynote slides on the net?
> > From past rumblings, I gather that Python is moving
> > towards preventing __builtins__ from being shadowed.
>
> You must be misunderstanding.
>
> The only thing I want to forbid is to stick a name in *another*
> module's globals that would shadow a builtin.
Yes, that *is* different.
Allowing shadows means having to watch out for trees.
> The idea of forbidding module B in the first example is that the
> optimizer is allowed to replace len(a) with a bytecode that calls
> PyOject_Size() rather than looking up "len" in globals and builtins.
> The optimizer should only be allowed to make this assumption if
> careful analysis of an entire module doesn't reveal any possibility
> that "len" can be shadowed
. . .
> BTW this idea is quite old; I've described it a few years ago under a
> subject something like "low-hanging fruit".
The fruit is a bit high. Doing a full module analysis means
deferring the optimization for a second pass after all the code
has already been generated. It's doable, but much harder.
def f(x):
return len(x) + 10 # knowing whether to optimize this
def g():
global len # when this is allowed
len = lambda x: 5 # is a bear
The task is much simpler if it can be known in advance that
the substitution is allowed (i.e. a module level switch like:
__fastbuiltins__ = True).
Raymond Hettinger
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4