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

Phillip J. Eby pje at telecommunity.com
Mon Apr 19 12:21:15 EDT 2004

At 08:25 AM 4/19/04 -0700, Guido van Rossum wrote:
> > I'd rather see something like:
> >
> >     from __future__ import fast_globals
> >
> > which would mean that globals and builtins could be considered
> > constants unless declared with 'global' at the module level.
>Don't you think that this should be flagged with syntax that doesn't
>permanently require the use of the word "future"?

I thought that the goal was to ultimately make at least builtins 
non-rebindable by default, without having flagged them as such.

>And I think that
>reusing the global statement at the global level is hardly the best
>way to do this.


>I do think that explicitly flagging "volatile" globals somehow might
>be the right way to go eventually, but it should only be required for
>those globals for which the compiler can't tell whether they may be
>modified (i.e. anything that is assigned to more than once or or from
>inside a loop or conditional or function is automatically volatile).

The issue I was addressing was whether another module is allowed to rebind 
them via setattr.

> > 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.)
>Huh?  If the object's identity is constant (which is what we're
>talking about) why should its *contents* be constant?  And who says
>setattr is the only way to modify an object?  Or am I misunderstanding
>what you're trying to say?  (I thought that "a constant bound into a
>function" would be something like a global/builtin name binding.)

Sorry, I was unclear.  I meant that the module object could disallow 
__setattr__(name,value) on *itself* for any name that was considered a 
"constant", because that name's binding had been copied into a function for 
use as a constant.

I wasn't trying to say that "constants" should be immutable; in fact there 
are plenty of use cases for mutable (but not rebindable) globals, such as 
module-level caches and registries.

More information about the Python-Dev mailing list