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.. ;-) -- Nick
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4