[Python-Dev] Fast access to __builtins__

[Guido van Rossum]

> Cool.  Any chance of getting your keynote slides on the net?

Yes, after the conference.

> > > 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.

Being poetic?

> > 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.

You're stuck in a one-pass compiler mindset.  We build a parse tree
for the entire module before we start generating bytecode.  We already
have tools to do namespace analysis for the entire tree (Jeremy added
these to implement nested scopes).

> 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).

-1000.

--Guido van Rossum (home page: http://www.python.org/~guido/)