[Python-Dev] Re: [Import-sig] Re: Proposal for a modified import
Prabhu Ramachandran <firstname.lastname@example.org>
Tue, 13 Nov 2001 10:38:34 +0530
>>>>> "JH" == Jeremy Hylton <email@example.com> writes:
>>>>> "PR" == Prabhu Ramachandran <firstname.lastname@example.org> writes:
JH> I haven't followed this thread closely. Is there some reason
JH> that explicit names in imports is not sufficient?
PR> Yes indeed there is. I've already explained my reasons twice.
PR> Eric also explained why this was important for Scipy.
JH> I have had a hard time trying to figure out precisely what the
JH> problems are.
I think you got it mostly right. Let me try to elaborate on it.
(1) Re-nesting a package is a pain. What I mean by re-nesting is
that say I have a package, A, that is separate (and that has its own
sub packages) and now I want it as part of another package, B. Lets
further suppose that the module which re-nests the package, B,
tracks the development of A and keeps their copy updated. In this
case A is developed as a standalone package and B adds something to
it that A cannot/refuses to use. With the current approach B would
be forced to modify A every time A changes in some significant way
simply because A was re-nested. Yes, this is contrived but such
situations do occur.
To make things clearer. My main objection is that the name of a
package when one imports it depends on its parent packages name.
This is IMHO absurd.
From sub1 if you had to import anything from sub you'd have to do
import foo.sub.module. So if foo is now part of something else -
you have to change all references to foo.
(2) If you have a complex package with more than 2-3 nested sub
directories it becomes a huge pain to use clean import statements
and not have to type long lines just to get to different modules.
(3) If you argue that import must always do only absolute imports
then why are sibling packages allowed? i.e. if there are two
modules in the same directory Python currently allows one to import
them with a relative name rather than an absolute foo.sub.pkg kind
of name. If this is valid, then its natural to expect that
searching also be done in the local package structure.
(4) Yes, its possible re-factoring code but sometimes this can be a
pain if you have a CVS tree and you want to re-organize your package
structure. Bernhard Herzog posted a solution for my specific
problem, so that really is not the issue. In my case the current
cvsroot for my sources is this:
and Bernhard's solution would create a directory structure like so:
Which is pretty crazy if you ask me, its bad enough as it is. :)
this will solve my particular problem but is dirty.
JH> What does "re-nesting" mean? It get the impression you mean
JH> putting one package inside another after it was developed and
JH> pacakged for use as a top-level package. If so, it doesn't
JH> seem like a problem that occurs that often, right? I'd be
JH> hesitant to add features to the import mechanism to cater to
JH> an infrequent case.
I've had about 4 others mailing me about their related problems. So I
wouldn't classify this as a rare problem that can be safely ignored.
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.
It all depends. I think Eric explained his position pretty clearly.
I'm convinced that Python's import structure needs improvement.
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.
Well, its all about convenience anyway - if not we'd all be talking to
computers in binary! <wink> Why do we need 'high-level' programming
languages? Yes, I'm digressing into te philosophy of computing but I
dont think syntactic sugar is something to be ignored because its
PR> from pkg import subpkg is also not the best way to do
PR> imports. I personally prefer import pkg.subpkg and I believe
PR> this is the recommended way of doing imports.
JH> Why do you think this is the recommended way of doing imports?
JH> I use both in my code and haven't been able to come up with a
JH> clear rationale for doing one or the other. The from
JH> ... import form seems useful when the name of the
JH> package/module is long or when it's only one or two names I'm
Well, the Python howto explains it much better than I could hope to:
Since re-loading packages is important for me, I prefer using plain