|
osdir.com mailing list archive |
|
Subject: Re: The meaning of "global variable" - msg#00071List: python.python-3000.devel> > Before it is reasonable to change the meaning of "global", we would > > need to have coherent answers to these questions: > > > > 1. What is the global namespace? > > Under the proposal, there is no such thing as > "the" global namespace, so the question is > meaningless. > > There's no such thing now, either -- there > are just (multiple) module-level namespaces. Okay... tell that to all the writers of Python books and webpages that mention "the global namespace". Should we remove any occurrences of this phrase from the official Python documentation as well? > > either you have > > to say (#1) there is no longer such a thing as "the global namespace", > > As I said, there isn't one now. Which namespace > is "the global namespace" depends on which module > you're looking from. Under the proposal, it would > depend on which scope you're looking from. No -- it's much worse than that. That's the problem: even if you know which scope you're looking from, you wouldn't be able to point to anything and say "that's the global namespace". If we repurpose "global" to mean "nonlocal", the declaration "global a, b, c" might mean that a, b, and c all belong to different namespaces. Right now, in any given context, "the global namespace" has a clear meaning: the namespace shared by the whole file. With the new meaning of the "global" keyword, "global namespace" becomes meaningless no matter what the context. In Python, the concepts of "global", "global variable", and "global namespace" are too well established to destroy. -- ?!ng Thread at a glance:
Previous Message by Date: click to view message previewRe: Path Reform: Get the ball rollingOn 11/2/06, Talin <talin@xxxxxxx> wrote: > One way to solve this would be to define a platform-neutral path > representation that can be "rendered" into either os-specific *or* > application-specific formats. I could read a Perforce path string, > convert that into an abstract path, do some work on it, and then convert > it back to a Perforce path - or convert to a local filesystem path if I > choose. Basically we'd have importers and exporters (format converters) > for paths. On Win32, for example, we could have an "NT" importer for > standard NT-style paths; a "Cygwin" importer that was more relaxed about > a mixture of forward- and back-slashes; and so on. > > Of course, there would always be a "shortcut" for the local filesystem > format - i.e., if no conversion was specified, then the local host > format would be used as the default. > > How such importers and exporters would actually look syntactically, I am > not sure yet. I'm open to ideas... This sounds like a use case for a directory-component path object. If it treats paths as sequences like ['usr', 'local', 'lib', 'python2.4'] and you had to input them that way too, it would be a platform-neutral format. You'd still need to specify absolute/relative path, and in some cases choose the root for an absolute path, which is why Noam's module uses a special "root object" for the first element. This weekend I plan to code up a MiniPath containing the pathname-manipulation features of PEP 355, a MediumPath subclass adding the filesystem-dependent methods that some ppl frown on, and a MaxiPath subclass with my favorite additional methods. I'm thinking of making the path module a class attribute, so that you can subclass any of these and use ntpath or macpath instead of your default if you want. I'll also try my hand at Glyph's "safe join" feature if I can get it to work right, but that will be an optional separate method: either a .child instance method or a class method (not sure which is better). -- Mike Orr <sluggoster@xxxxxxxxx> Next Message by Date: click to view message previewRe: Draft PEP for outer scopesGreg Ewing wrote: > Besides, the BDFL is going to do whatever he wants > anyway, so let's just leave him to get on with it. :-) but where is he? has anyone seen him lately ? </F> Previous Message by Thread: click to view message previewRe: The meaning of "global variable"Greg Ewing wrote: > Ka-Ping Yee wrote: >> Before it is reasonable to change the meaning of "global", we would >> need to have coherent answers to these questions: >> >> 1. What is the global namespace? > > Under the proposal, there is no such thing as > "the" global namespace, so the question is > meaningless. > > There's no such thing now, either -- there > are just (multiple) module-level namespaces. I think that the argument that "there's no such thing as a global namespace, either now or in the future" are using an overly pedantic definition of the word "global". In Python "global" means, and has always meant, the namespace of the current module. It is the namespace that is "outside of any function definition", and that is true regardless of which module we are talking about. It is a "special" namespace because it has different semantics than the namespaces that are defined within a function scope. You can't just hand-wave this away - the 'global' namespace is far too important and useful to be just dismissed out of hand. I think the confusion stems from the fact that in many contexts, the word 'global' is a synonym for 'universal'. However, there's more than one planet in the universe...and no one is arguing that global variables in Python are in any way 'universal' variables. -- Talin Loading Comments...
|
|
