[Python-Dev] Relative Package Imports
Thu, 16 Sep 1999 12:56:01 +0200
Tim Peters wrote:
> Sure is a lot of traffic on this -- can't we go back to hating the new
> license <wink>?
The license was withdrawn... I would prefer starting to talk about
> > Also, I don't know how "explicitly, long-windedly and straightforwardly"
> > writing module imports is any different from using relative imports.
> Hugely and profoundly different, as your example shows:
> > An example:
> > mx
> > .DateTime
> > .ODBC.Windows
> > In ODBC.Windows I would write:
> > import __.__.DateTime
> > which is just as explicit as writing
> > import mx.DateTime
> > except that the information about the top-level hierarchy is *not*
> > included in the import information.
> Exactly: now instead of a bulletproof absolute import in a self-contained
> importer, whose precise meaning is clear from casual static inspection,
Ah, that's a new idea ! Package local absolute names... wow, that
> you've got a relative one whose meaning depends vitally on where the
> importer happens to live. As code moves around, the import may fail to work
> when you're lucky, or pick up an unintended DateTime package when you're
> not. The semantics of the import are indeed relative now: you see the
> opportunity to type three additional characters <wink> as a strength, and I
> see nothing but headaches masquerading as convenience.
Tim, the intention was being able to move the mx level around, e.g.
renaming it, eliminating it by sticking DateTime and ODBC under
some other higher level package (yes, you'll have to watch out
here because the higher level package might define DateTime and ODBC
too -- but it's not all that likely), etc.
The buzz word here is 'relocatable'.
> As further consequence, simple "search-and-replace" strategies are rendered
> at best useless. That is, a simple grep can no longer find all & only
> references to mx's flavor of DateTime: it picks up all references to all
> DateTime guys, with no way short of a structure-aware tree crawler to sort
> them out again. Complexity spreads.
> Of course, in the end, I lose no matter what. If *everyone* used dirt-dumb
> fully-qualified imports, all hassles with shifting package structure could
> be solved with a text editor in seconds. But that's not whiz-bang enough,
> so people *will* play endlessly dubious tricks with hooks, paths, relative
> imports, and metapackages too once Gordon gets around to them <wink>.
> Having an explicit way to spell relative imports would make my life easier
> because at least those are statically recognizable for what they are. I
> don't want them and won't use them, but it could ease the pain others will
> cause by using them. That's not enough to make me in favor of them, though;
> just enough so I won't pout if they do go in.
> > Anyway, I'm not too inclined continuing this discussion anymore.
> > I would never have thought that such a nifty little patch would
> > have stirred up so much negative response. I'll just hack up my
> > very own import mechanism using imputil and be done. So there!
> Don't feel picked on, M-A! Opposition is normal and healthy; and the last
> idea I got anywhere with was list.pop().
Yah well. Last thing I succeeded with was making Python methods
wrap any callable type.
Seems that we're a bit too healthy (see MarkH's post) sometimes,
i.e. there isn't all that much room for experiments. Just think
of cool developments like Chris' stackless python. Experience shows
that these kind of things will never make it into the distribution.
Unfortunately, maintaing patches to the dist across releases a real
pain and much work, so these ideas will just sit there unused and
untested. Much the same happened to gcc ... in the end corporate
strength made egcs possible. Perhaps we need such a branch too ?
Y2000: 106 days left
Python Pages: http://www.lemburg.com/python/