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

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 fastglobals > > 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.

Okay.

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