[Python-Dev] Relative Package Imports

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [MAL]
> > I agree that it's ugly to include the __ attribute in the module
> > namespace due to the possible circular reference (parent->module,
> > module->parent), but the patch I sent doesn't do this... or was
> > "ugly" referring to the two underscores looking strange ?
> >
> > Could you elaborate a bit on the reasons for dropping __ support ?
> 
> There are two sections on why __ was dropped in
> 
>     http://www.python.org/doc/essays/packages.html
> 
> They don't refer to circularity, but to "limited use", "poor readability"
> and "awkwardness". 

Ok, so the two underscores look strange... that's arguable. "Limited
use" is not: there clearly is a use for relative imports. Please
remember that we are talking about package internals here -- not
user interfaces of that package. 

> A deeper reason may be hiding in the essay's "most
> packages will have a relative shallow substructure":  this is Guido <wink>,
> the man who invented two-level scoping, and class inheritance without a
> "super" hook back to the (anonymous) parent.  For all Python's dynamicism,
> it very much favors shallow, static name hierarchies.  I don't think it's
> coincidence that Python's own source code is in a two-level directory
> structure either!  The only #include with a ".." is in grammar.h, and there
> it's in a comment <wink>:
> 
>     #include "bitset.h" /* Sigh... */
> 
> So if we cut to the core here, I'd bet Guido doesn't object so much to
> relative imports as to the idea that anyone would go off and create a
> package structure so fractally convoluted that relative imports are strongly
> more attractive than naming the target package in full.

This is not the intention of relative imports. Its all about
making packages relocatable. And that's a Good Thing IMHO.

> Or maybe Guido doesn't care about that at all.  I do regardless.  I know
> Python's restrictions can grate, but in all, and in my repeated experience,
> they force you to rethink complicated designs and refactor them into simpler
> schemes that fit what Python is best at spelling.  Nesting packages 8 deep
> is clumsy now?  Damn straight, and I'm thankful for that:  the clumsier it
> is, the less gratuitous inherited complexity I'll have to deal with in my
> future lives <0.5 wink>.

Tim, I promise you not use 8 levels deep ;-) I usually create
my packages using at most two levels (moving to at most three levels
in future mx package releases) and even better: the common
package interfaces are all available at the top-most level while
internal stuff hides in higher levels.

You don't have to think much about the internal structure of
the package while you use it. That's something I have to worry
about and the advantages of relative imports show up in such
a context which is why I posted the patch.

> Things that came up in this thread that are worth fixing include:
> 
> + Problems with persistent class references (incl. pickles).
> 
> + Dealing with incompatible versions of packages.  If someone wants to embed
> a copy of (say) mxDateTime in their own package, the only excuses are that
> they're afraid of overwriting the user's existing mxDateTime installation
> (if any), and/or of having some future installation of something else
> overwrite mxDateTime with an incompatible version.  Those are bad problems,
> but package embedding is no solution.  You have a much better approach to
> that already via the DateTime.__version__ string!  "Something like that"
> needs to be formalized and imposed on all public packages.

So the distutils will have to check for already installed package
versions and warn about conflicts. Right, that's something which 
definitely needs to become a standard (too ;).

> at-which-point-the-distutils-sig-jumps-in-and-saves-the-day-ly y'rs  - tim
> 
> PS:
> 
> > Just think of what happens to Win9x if you constantly update the DLLs...
> 
> As a matter of personal experience, it gets much stabler!  The older DLLs
> get replaced by less-buggy newer ones, thanks to version numbers, rules, and
> installers that finally play by the rules.  The mean time between crashes
> when I installed Win95 a few years ago was about an hour; now it's at least
> days and possibly weeks (don't know -- never leave the puter on that long).
> When a version upgrade fails, it's not a mystery, it's a bug <0.9 wink>.

My experience is that intra-DLL references simply don't match anymore
and cause the system to become instable. Also, some weird installers
don't care about the version numbers and install older versions at
their will. The outcome is a complete version mess.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   108 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/