[Python-Dev] Relative Package Imports
Tue, 14 Sep 1999 03:02:24 -0400
> 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
They don't refer to circularity, but to "limited use", "poor readability"
and "awkwardness". 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.
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>.
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.
at-which-point-the-distutils-sig-jumps-in-and-saves-the-day-ly y'rs - tim
> 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>.