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

Brett C. bac at OCF.Berkeley.EDU
Mon Apr 19 14:24:00 EDT 2004

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

Just to make sure I am understanding this, are you suggesting a possible statement like volatile len to flag that len may be changed? That way all "volatile"-flagged globals and one that are redefined in the module use LOAD_GLOBAL while all other built-ins either get them set to locals or use a LOAD_BUILTIN opcode?

Or am I getting the use of volatile reversed (which would make more backwards-compatible)?

If we go with the former interpretation I take it we would still need to get that warning Neil worked on a while back for warning people when someone is injecting into a module's global namespace.

-Brett

More information about the Python-Dev mailing list