On 7/1/06, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 6/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 6/30/06, Steven Bethard <[EMAIL PROTECTED]> wrote: > > > On 6/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > On 6/30/06, Steven Bethard <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
