[Barry] > > That's why when I tend to think about this, I start wanting a way to > > spell "definitely give me the global one, no matter what". IOW, I feel > > like I want a way to bypass relative module lookups. [Paul Moore] > That issue I can understand. And I agree there should be a way to > state it explicitly. > > One of the issues here is that this area is a bit under-documented (I > know, I should read the source, but I don't have the time right now). > > At the moment, there are two cases: > > 1. Import from sys.path. This is what is being called an "absolute" > import, and is nice and easy to understand. The key issue is that > there is no way to *force* this interpretation in the face of > option (2) below. Right. > 2. Import from "the package". This is the under-documented bit, but if > I understand it correctly, it's basically that from within a module > contained in a package, sys.path is conceptually *extended* to > include the package's __path__ (which by default contains the > directory of the package, but which can be user-modified). That's not a very useful way to think about it; when the module is found on __path__ something very *different* happens than when it is found on sys.path. The difference is noticeable if you ask the imported module for its __name__. If you the import was satisfied from __path__, then __name__ will include the package name. If it was satisfied from sys.path, it won't. And __name__ is related to module identity: all modules are stored in sys.modules using their __name__ as the key, so multiple imports of a module with the same __name__ end up referring to the same module (and only the first import causes the module's code to be executed). > Now the big problem here is that behaviour (2) is useful. Simple > "relative" imports of one module within a package from another module > in the same package are common. Guido's (IMHO ugly) "dot" syntax > handles that, by making users explicitly request option (2), and > making the current import syntax *only* mean (1). Actually, what you consider useful is considered harmless by others. Many large packages, including Zope, have adopted a rule of always using absolute imports, to clarify what kind of import is being used. > But none of the proposed solutions handle the __path__ variable. I > don't have any objection in principle to desupporting __path__ (heck, > it would have made thinking about PEP 302 easier, if nothing else) but > (a) it would need a deprecation warning, and (b) Guido himself offered > a use case in <http://www.python.org/doc/essays/packages.html>. __path__ has no bearing on the proposals, it is used for relative imports. I think your confusing about how the current import works caused you to think it is relevant. > This definitely needs a PEP. If we're removing support for __path__, > the implications need to be thought through (PEP 302, the pkgutil > module, etc etc). If we're not, none of the proposals so far have > covered how __path__ gets supported in future. We're not, but they have (by not mentioning it); but I agree that a PEP is needed. > A much simpler proposal, just providing an explicit way of saying > "Import from sys.path *only*" may be OK without a PEP. But even then, > I'd suspect we should have a PEP explaining *why* it has to be this > simple. This was where this thread started: someone proposed a way of spelling "import from sys.path only". My big problem with that is that *most* imports are intended to be satisfied by sys.path only, so this spelling should be the default, meaning the current spelling. > Go on, Guido. We'll be gentle if you write a PEP, and we won't set > c.l.p on you :-) Alas, I have no time. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4