Guido van Rossum <[EMAIL PROTECTED]> wrote: > > In a recent discussion in a SF patch, I noticed that PEP 328* only seems > > to support relative imports within packages, while bare import > > statements use the entirety of sys.path, not solving the shadowing of > > standard library module names. > > Hm. I'm not convinced that there is a *problem* with shadowing of > standard library module names. You shouldn't pick a module name that > shadows a standard library module, or if you do you shouldn't want to > be able to still use those modules that you're shadowing. Anything > else is just asking for trouble.
While I personally don't tend to use names previously existing in the standard library, seemingly a large number of people do, hence the not-so-rare threads on comp.lang.python which ask about such things. > > More specifically; after a 'from __future__ import absolute_import' > > statement, any import in the module performing "import foo" will only > > check for foo in the standard library, and the use of the leading period, > > "from . import foo", the will signify relative to the current path. ** > > And how exactly do you define "the standard library"? Anything that's > on sys.path? That would seem the only reasonable interpretation to me. > So I take it that you want the "script directory" off that path. > (Let's for the sake of argument call it ".".) Sounds reasonable to me, with one caveat; if one were to consider everything on sys.path to be in the standard library, then every script ever written for Python, which doesn't remove the standard ''/'.' from sys.path, would be part of the standard library. I would suggest, as a replacement definition (probably with a caveat or two), that any module with a reference in the documentation, that also lies on the default sys.path, which is shipped with Python that is distributed at python.org, is part of the standard library. > > The lack of a 'from __future__ import absolute_import' statement in a > > module will not change the import semantic of that module. > > It's hard to imagine how this would work. sys.path is global, so > either "." is on it, or it isn't. So things in "." are either > considered part of the standard library, or they are not; this can't > be made dependent on the module's importation of something from > __future__. Perhaps not, but in the process of importing a module into a namespace, one can check for the existance of the object imported from __future__, and ignore or not the "." entry in sys.path. > > This allows current code to continue to work, and for those who want to > > choose names which shadow the standard library modules, a way of dealing > > with their choices. > > My suggested way of dealing with their choices is summarized in the > first paragraph of my reply above. Perfectly reasonable. I can think of examples where it would not be reasonable, but they are quite cooked *wink*. > > Alternatively, PEP 328 could be implemented as-is, and a second future > > import could be defined which offers this functionality, being > > permanently optional (or on a different timeline) via the future import. > > I don't like permanently optional language features; that causes too > much confusion. I'd much rather settle on clear semantics that > everyone can understand (even if they may disagree). > > But I certainly would prefer that the proposed feature becomes a > separate PEP which can be discussed, accepted or rejected, and > implemented separately from PEP 328, which is complete and accepted > and just awaiting someone to implement it. Sounds good. I'll see what I can do this weekend about getting a proto-pep started. > > Essentially, it would ignore the empty path "" in sys.path when the > > functionality has been enabled via the proper future import in the > > current module. > > But it's not always "" -- it's the directory where the "main" script was > found. > > Let me explain the biggest problem I see for your proposal: what would > be the canonical name for a module imported using your "new relative > semantics"? Remember, the canonical name of a module is its __name__ > attribute, and the key that finds it in the sys.modules dict. Because > there's only one sys.modules dict (barring restricted execution > sandboxes), the canonical name must be unique. So if there's a > standard library module string, its canonical name is "string". Now > suppose you have your own non-standard-linrary module read from a file > string.py. What should its canonical name be? It can't be "string" > because that's already reserved for the standard library module name. > > The best solution I can think of for this off the top of my head is to > somehow allow for the arrangement of a pseudo-package named __main__ > and to make all these non-standard-library modules reside (logically) > in that module. If you can write a PEP along those lines you may be on > to something -- but I expect that the way to turn it on is not to > import something from __future__ but perhaps from __main__. I'm not > exactly sure how to get "." off sys.path, but maybe you can think > about that for your PEP proposal. What do you say? You make very good points about naming in sys.modules. I will think about this and place some options in the proto-pep. Thank you, - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com