On Apr 19, 2004, at 2:24 PM, Brett C. wrote:
Guido van Rossum wrote:
I'd rather see something like:
from __future__ import fast_globals
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)?
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.. ;-)