[Python-Dev] PEP 329: Treating Builtins as Constants in the Standard Library (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Apr 19 10:39:06 EDT 2004

At 09:55 AM 4/19/04 -0400, Raymond Hettinger wrote:

> I'm not sure I understand the reasoning for implementing this via a > bytecode hack, rather than in the compiler or loading mechanisms.

The reason is that it is not always possible to know (in general) what things constants. Take a look at the ASPN recipe example, it ought to clarify for you how this works.

I don't need clarification about the mechanism; I independently implemented exactly this hack myself a couple of years ago. (I just didn't propose it become part of standard Python.) See 'bind_func()' in:

http://cvs.eby-sarna.com/PEAK/src/peak/util/Code.py?rev=1.1.2.1&content-type=text/vnd.viewcvs-markup

> from future import fastglobals

The future mechanism is a transitional approach for things that would break existing code.

Right, and the slightly broader proposal I made would break existing code, but in a direction that Guido has said before he'd like to move.

Also, future statements go at the beginning of a script and the proposed bindall goes at the end.

Which is a good argument for why the future statement is a much better idea. :)

> which would mean that globals and builtins could be considered constants > unless declared with 'global' at the module level. Then, the compiler > could optimize any undeclared builtins, and the 'MAKEFUNCTION' opcode > could bind any constants defined as of the function's declaration. > > Finally, the module object thus created would ban any setattr on any > constant that has been bound into a function. (Since these are the only > setattrs that could cause harm.)

IMO, this is making something hard out of something simple.

No, it's trying to advance the language, rather than merely its implementation, and thus make it easier for Jython, IronPython, et al to cope.

Try applying the working code in the PEP to a few modules.

Given that I've had this hack in my CVS repository for a few years now, you will probably realize that I already have. :)

More information about the Python-Dev mailing list