[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:
> > 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
> > which would mean that globals and builtins could be considered
> > 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
> > constant that has been bound into a function. (Since these are the
> > 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