On Tue, 2003-12-16 at 09:17, Gustavo Niemeyer wrote: > I have done this many times, so let me try to describe at least one > legitimate usage case. > > A couple of weeks ago I wrote a software which needs a third > party package to work. OTOH, since it's a small package, I don't > want to force the user to go after the package, even because I'd > have to ensure that my code always work with the available version > of that package. > > Thanks to the relative module importing mechanism, solving that is no > harder than copying the third party package into my own package > namespace. > > This idea could probably be expressed in some other way, hacking > sys.path or whatever, but I belive this is a fairly common pattern, > and I vote for introducing a scheme to differ between local/global > importing which would not break the current flexibility. I guess the difference is when you're writing an application vs. writing a library. When writing an application (like Zope or Mailman), we already manipulate sys.path to include some non-standard locations. Incorporating a third-party package into the application then is a simple matter of arranging to have its top level directory somewhere on sys.path. In Mailman, I do this with the email package, and various codecs. When writing a library, that's harder because you're imposing requirements on the downstream consumer of your library. As an application developer, I don't have much sympathy for relative imports. As a library developer, I can see the point. -Barry
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