[Python-Dev] Relative Package Imports

M.-A. Lemburg mal@lemburg.com
Wed, 15 Sep 1999 11:24:43 +0200


Tim Peters wrote:
> 
> + The notion that Python packages aren't self-contained now is wrong:  a
> package module can import other modules in the package without
> qualification.  This is good design.

Agreed. And we would like to take that notion one step further --
without breaking the two-scope resolution Python uses now. The
'__' tags are just place holders which could just as well be
handled by a simple Python fuction (like the one Gordon posted)
using perfectly valid technology.

Sticking this technology into the import statement is really only
a more elegant approach. Nothing more. The whole thing already
works using the current Python implementation.

> + JimF and MAL's shared notion that they're the only ones making significant
> use of packages is myopic. 

Oh, c'mon Tim, we never did say that. We only mentioned having used
package for quite a while. This includes having seen all the different
pitfalls they have to offer.

> Dragon also uses packages, and heavily, although
> products using them have not been announced and I can't talk about them yet.
> Anything I'm within 10 miles of doesn't use *any* import hooks, or play any
> other tricks on the system.  Instead I urge people to write their imports as
> explicitly, long-windedly and straightforwardly as possible (with binding to
> a convenient local alias name on the following line).  Do we embed
> sub-packages?  Sure.  Do modules move around in the hierarchy over time?  Of
> course.  So how do we deal with this supposed nightmare?  Because all
> imports are relentlessly straightforward (even intra-package imports are
> fully qualified), and none are hiding in dynamic functions, we get into
> Emacs and do a global search-and-replace.  Takes 30 seconds, and the new
> structure is plain as day to everyone reading the code.

This is perfectly ok if you're just using your own code, but it
gets a mess when third-party packages are involved simply because
you can't be sure they don't use import hooks, local imports or
hacks to __path__ etc. If you still want them to be useable, you'll
have to go down and dive into their structure. This takes time, is
error prone and not necessarily fun.

Also, I don't know how "explicitly, long-windedly and straightforwardly"
writing module imports is any different from using relative imports.

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.

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!

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