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