A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-December/041056.html below:

[Python-Dev] Re: Christmas Wishlist

[Python-Dev] Re: Christmas Wishlist [Python-Dev] Re: Christmas WishlistGustavo Niemeyer niemeyer at conectiva.com
Tue Dec 16 09:17:46 EST 2003
> But why do you have to give those packages a different full name?
> That's the question that I've never seen answered adequately.

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.

-- 
Gustavo Niemeyer
http://niemeyer.net

More information about the Python-Dev mailing list

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