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

Guido van Rossum guido at python.org
Mon Apr 19 14:35:10 EDT 2004

[Phillip Eby]

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

[Guido van Rossum]

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

[Brett Cannon]

Just to make sure I am understanding this, are you suggesting a possible statement like volatile len to flag that len may be changed?

Yeah, but not that syntax. (I'm not proposing any syntax at this point.)

That way all "volatile"-flagged globals and one that are redefined in the module use LOADGLOBAL while all other built-ins either get them set to locals or use a LOADBUILTIN opcode?

Sort of, although I think you meant STORE_GLOBAL rather than LOAD_GLOBAL. Exactly how this would be implemented is up to the bytecode compiler; I can see that some cheap builtins (e.g. len) may be turned into special opcodes so that no lookup is used at all.

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

You're not getting it reversed. Having to flag the ones that are not volatile would indeed be more backward compatible, but it would require everybody to put lots of 'nonvolatile' statements in all the time just in the hope to get faster code. That's what I'm trying to avoid, and that's why I'm not psyched about Raymond's (or anybody's!) proposed "make this function faster" API. Given that "volatile" globals are very rare, it makes more sense to put the burden on the programmer who needs his seemingly-constant globals to be reloaded.

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.

Yeah, that warning is still the right thing to do, but it's implementation was a nuisance because there were some legit cases that it couldn't know about. I don't recall -- did we turn it into a silent deprecation or did we just delete the warning?

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

More information about the Python-Dev mailing list