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

Nick Bastin nbastin at opnet.com
Mon Apr 19 14:37:34 EDT 2004

On Apr 19, 2004, at 2:24 PM, Brett C. wrote:

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 LOADGLOBAL while all other built-ins either get them set to locals or use a LOADBUILTIN opcode? Or am I getting the use of volatile reversed (which would make more backwards-compatible)?

You could, of course, create a statement like "const len" to flag that len will NOT be changed, thus creating true backwards compatibility, but you'd like to believe that const is the 95% use case, and thus it should be "volatile foo" when you want to change foo, but that's not all that backwards compatible. Of course, you could add something like "from past import volatile_globals", and "from future import const_globals" for a release.. ;-)

-- Nick

More information about the Python-Dev mailing list