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

Guido van Rossum guido at python.org
Tue Apr 20 12:50:19 EDT 2004

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

More information about the Python-Dev mailing list