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

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 fast_globals
>
>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 bind_all 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 'MAKE_FUNCTION' 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