[Python-3000] replace globals() and global statement with global builtin object
Guido van Rossum
guido at python.org
Sun Jul 2 19:44:52 CEST 2006
On 7/1/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 6/30/06, Guido van Rossum <guido at python.org> wrote:
> > On 6/30/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > > On 6/30/06, Guido van Rossum <guido at python.org> wrote:
> > > > On 6/30/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> > > > > BJörn Lindqvist wrote:
> > > > > > I have often wanted something similar to that for global
> > > > > > variables, instead of the global declaration:
> > > > > >
> > > > > > cache = None
> > > > > > def init():
> > > > > > if not global.cache:
> > > > > > global.cache = init_cache()
> > > > >
> > > > > Redirected since this seemed like a Python 3000 kind of request. I
> > > > > like the idea, particularly because it coincides well with my usual
> > > > > uses for global/globals(). Seems like it might require some changes
> > > > > in things like eval and exec that take locals and globals dicts, but I
> > > > > don't know how much of a drawback that is.
> > > >
> > > > You realize that *reading* a global doesn't need the "global." prefix,
> > > > do you? So you could have written "if not cache: global.cache =
> > > > init_cache()" in the function body.
> > >
> > > That's also true for the global statement, right? That is, the ``if
> > > not cache`` part would not need a global statement, whlie the ``cache
> > > = init_cache()`` part would.
> > >
> > > That said, I agree it does nothing to solve the asymmetry.
> > At least with the global statement, the notation for the variable
> > reference remains the same. E.g. you can write
> > x = f(x)
> > and everybody will understand that the x on the left and right refer
> > to the same variable.
> > You'd lose that with
> > globals.x = f(x)
> > IMO that's enough of a drawback to give it a solid -1.
> Sounds reasonable. Should I update PEP 3099? Something like this
> comes up every few months.
Yes, with reference to this thread.
> Oh, also, is the -1 only to replacing the global keyword? Or is it
> also to the idea of replacing globals() with a builtin
> pseudo-namespace object like the one above?
The -1 is specifically for the idea that globals.foo would be a way to
reference the global variable foo.
I personally don't consider the global statement a mistake, so I don't
really want to have to think about changing it in py3k (there's enough
that I *do* want to change). But I'm not quite feeling strongly about
not messing with global as I feel about the particular proposal that
started this thread, so I don't yet want to add "improve global" as a
no-no to PEP 3099.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000