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