[Python-Dev] Re: [Python-checkins] python/nondist/peps pep-0329.txt, 1.2, 1.3

[Guido van Rossum]

> Would it be salvageable if it were changed to:
> 
> * Get rid of bytecode hacking, in favor of a change to the compiler
> 
> * Optimize builtins *only*, and only those that are never assigned to by 
> the module
> 
> * use a __future__ statement to enable the behavior initially, before 
> making it the default in a future release
> 
> * have module.__setattr__ warn when shadowing a previously unshadowed 
> builtin (unless the module uses the __future__ statement, in which case 
> it's an error)
> 
> Would this be acceptable?  It seems to me that this approach would
> allow Jython and IronPython the option in future of replacing
> lookups of builtins with static field accesses and/or method calls,
> which would give them quite a potential performance boost.

It is quite the opposite of the PEP!  The PEP proposes a quick, very
visible hack that works only for one implementation; your proposal
here lays the foundation for changing the language to enable the same
kind of optimizations.

I like that much better, but I doubt that it is doable in the
timeframe for 2.4, nor do I think it is needed.  Also, your 4th bullet
proposes exactly (except for the __future__ statement) what was
implemented in moduleobject.c in rev 2.46 and then withdrawn in rev
2.47; it is not feasible for a number of reasons (see python-dev for
the gory details; I don't recall what they were, just that they were
convincing).

The __future__ statement sounds like an excellent idea to me, as it
enables experimentation with the new feature.  One thing: we need to
specify the future behavior very carefully so that other Python
implementations will be able to do the right thing without having to
reverse-engineer CPython.

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