>>>>> "BAW" == Barry A Warsaw <barry@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.
BAW> Note that applications can achieve the same thing without
BAW> editing code by doing sys.path manipulations.
Its not the application that I'm concerned about - an application is
typically a single/few file(s) and editing them to suit things is
certainly not an issue. But editing 100 files inside a package each
time the parent changes is nuts.
There is another way to get around this by manipulating __path__
inside a sub package. But this leads to the same module being
imported several times. This is what I use currently and its evil. :(
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.
BAW> Indeed. We've been here before (perhaps, several "befores"
BAW> :). Every time this comes up I get the feeling like there
BAW> are easy ways to accomplish what you want if you think of the
So do I need to write a PEP? Is there some special formality/format I
need to keep in mind?
BAW> problem differently, or I'm missing something fundamental
BAW> about the problem, and/or the problem has never been
BAW> specified identified, or people are trying to solve too many
BAW> problems at once.
BAW> Are the needs of application authors different than library
BAW> authors?
I would think so.
prabhu
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