[Python-Dev] PEP 329: Treating Builtins as Constants in the Standard Library

[Nick Bastin]

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