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

[Guido van Rossum]

[Phillip Eby]
> >>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.

[Guido van Rossum]
> > 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).

[Brett Cannon]
> Just to make sure I am understanding this, are you suggesting a possible 
> statement like ``volatile len`` to flag that len may be changed?

Yeah, but not that syntax.  (I'm not proposing any syntax at this point.)

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

Sort of, although I think you meant STORE_GLOBAL rather than
LOAD_GLOBAL.  Exactly how this would be implemented is up to the
bytecode compiler; I can see that some cheap builtins (e.g. len) may
be turned into special opcodes so that no lookup is used at all.

> Or am I getting the use of volatile reversed (which would make more 
> backwards-compatible)?

You're not getting it reversed.  Having to flag the ones that are not
volatile would indeed be more backward compatible, but it would
require everybody to put lots of 'nonvolatile' statements in all the
time just in the hope to get faster code.  That's what I'm trying to
avoid, and that's why I'm not psyched about Raymond's (or anybody's!) 
proposed "make this function faster" API.  Given that "volatile"
globals are very rare, it makes more sense to put the burden on the
programmer who needs his seemingly-constant globals to be reloaded.

> 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.

Yeah, that warning is still the right thing to do, but it's
implementation was a nuisance because there were some legit cases that
it couldn't know about.  I don't recall -- did we turn it into a
silent deprecation or did we just delete the warning?

--Guido van Rossum (home page: http://www.python.org/~guido/)