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

Guido van Rossum guido at python.org
Mon Apr 19 11:25:26 EDT 2004

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"? 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).

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

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list