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