[Python-Dev] PEP 329: Treating Builtins as Constants in
the Standard Library
Phillip J. Eby
pje at telecommunity.com
Mon Apr 19 12:21:15 EDT 2004
At 08:25 AM 4/19/04 -0700, 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"?
I thought that the goal was to ultimately make at least builtins
non-rebindable by default, without having flagged them as such.
>And I think that
>reusing the global statement at the global level is hardly the best
>way to do this.
Okay.
>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).
The issue I was addressing was whether another module is allowed to rebind
them via setattr.
> > 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.)
Sorry, I was unclear. I meant that the module object could disallow
__setattr__(name,value) on *itself* for any name that was considered a
"constant", because that name's binding had been copied into a function for
use as a constant.
I wasn't trying to say that "constants" should be immutable; in fact there
are plenty of use cases for mutable (but not rebindable) globals, such as
module-level caches and registries.
More information about the Python-Dev
mailing list