> 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). > Finally, the module object thus created would ban any __setattr__ on > any constant that has been bound into a function. (Since these are > the only setattrs that could cause harm.) Huh? If the object's identity is constant (which is what we're talking about) why should its *contents* be constant? And who says setattr is the only way to modify an object? Or am I misunderstanding what you're trying to say? (I thought that "a constant bound into a function" would be something like a global/builtin name binding.) --Guido van Rossum (home page: http://www.python.org/~guido/)
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