[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