Barry Warsaw <barry at python.org> writes: > On Tue, 2003-12-16 at 13:26, Guido van Rossum wrote: >> A lot people have presented a good case for relative imports. Nobody >> has argued to keep the status quo (where imports are ambiguous about >> whether they are meant to be absolute or relative). So I suggest that >> in 2.4, we introduce the leading dot notation for relative import, >> while still allowing relative import without a leading dot. In >> 2.5 we can start warning about relative import without a leading dot >> (although that will undoubtedly get complaints from folks who have >> code that needs to work with 2.3 still). In 3.0 we can retire >> ambiguous import. > > I'll just note that where the current status quo trips /me/ up most is > when I accidentally have a local module with the same name as a global > module, and then I write an import statement expecting to get the > standard library module, but end up getting the local module. > > 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. 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. 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). 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). 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>. 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. 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. Go on, Guido. We'll be gentle if you write a PEP, and we won't set c.l.p on you :-) Paul. -- This signature intentionally left blank
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