[Python-Dev] PEP 329: Treating Builtins as Constants in
the Standard Library
Brett C.
bac at OCF.Berkeley.EDU
Mon Apr 19 14:24:00 EDT 2004
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
More information about the Python-Dev
mailing list