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/2001-November/018574.html below:

Proposal for a modified import mechanism.

[Python-Dev] Re: [Import-sig] Re: Proposal for a modified import mechanism. [Python-Dev] Re: [Import-sig] Re: Proposal for a modified import mechanism.Barry A. Warsaw barry@zope.com
Mon, 12 Nov 2001 17:32:27 -0500
>>>>> "JH" == Jeremy Hylton <jeremy@zope.com> writes:

    JH> I'd rather see the imports be explicit "import root.a.b.c"
    JH> than "import b.c".  Then re-nesting requires all the import
    JH> statements to be edited.  It's more typing and might even
    JH> require a simple script to do search-and-replace, but it
    JH> doesn't sound like a prohibitive burden.

Note that applications can achieve the same thing without editing code
by doing sys.path manipulations.

    JH> I expect there is more to the issue than just wanting to avoid
    JH> some extra typing.  A short PEP that describes the specific
    JH> problems being solved and discussing alternatives would help.

Indeed.  We've been here before (perhaps, several "befores" :).  Every
time this comes up I get the feeling like there are easy ways to
accomplish what you want if you think of the problem differently, or
I'm missing something fundamental about the problem, and/or the
problem has never been specified identified, or people are trying to
solve too many problems at once.

Are the needs of application authors different than library authors?

-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