[Import-sig] Re: (Serious?) package namespace problem (and a proposal)

Gordon McMillan gmcm@hypernet.com
Fri, 30 Jun 2000 11:45:39 -0400


M.-A. Lemburg wrote:

> Gordon McMillan about relative imports:
> > 
> > > > Their main feature is "ease of use", which can be
> > > > pejoratively cast as "programmer laziness".
 
> Simple: relative imports are not an artifact of "programmer
> laziness". What goes on inside a package is up to the programmer.
> How it can be installed is part of the published package
> interface.

Should it not be a rule that package authors *never* put 
scripts inside their packages? And how will you prevent a user 
from being inside your package when they start Python? 
 
> With the current setup, the only way to install a package is to
> make it top-level. Relative imports would make it possible to
> also install the package under some other top-level package (and
> it would still work as before).

Why on earth is this considered necessary or even desirable? 
Is there any precedent? Does any other language with some 
concept of packages allow this? Or is this a "wouldn't it be 
cool..." (which I predict would turn out to be an absolute 
disaster).
 
You started out by saying "How it can be installed is part of 
the published package interface". And then you say you want 
to be able to install as a subpackage of another package.

So I conclude once again that this is all for *your* convenience 
and the user can go take a hike. You're not giving them the 
choice of how to install.

> > It makes your life easier. It does not make your users' lives
> > easier.
> > 
> > Or have you missed the fact that I've had to explain on c.l.py
> > (at least 3 times) that various strange problems with mx
> > packages stem from misunderstanding how to install them on the
> > path?
> 
> I know that people have problems with packages in general
> (not only the mx ones, although these were among the first
> to use the mechanism). Most of these are related to PYTHONPATH
> and their understanding of how imports work in Python.

Why do you blame the users when you could prevent all these 
problems by using absolute imports?
 
How many developers understand the way imports work in 
Python? Heck, Guido thanked me when I handed out structure 
diagrams at the dev-day talk.

> With distutils all of these problem will hopefully go
> away...

Absolute nonsense.
 
> > When "import mxDateTime" doesn't throw an exception,
> > people for some reason expect to be able to *use*
> > mxDateTime.
> 
> Could you explain this ? "import mxDateTime" will normally only
> work inside the package (or if the user ran "make install"
> instead of just "make"). All other cases should yield an import
> error.

Sorry, I used the wrong overloaded name.

>>> import DateTime
>>> DateTime.ARPA
Traceback (innermost las
  File "<stdin>", line 1
AttributeError: ARPA
>>>

Distutils won't fix that. (Even Toby's & Just's suggestions that 
relative imports be spelled differently won't fix that.)

> Note that some time ago I proposed to add relative imports
> by changing the lookup mechanism to something more easily
> understood. Basically what happens is that import searches
> up the package hierarchy if can't find the module at the
> current level -- very simple, very effective.

You go on c.l.py and explain to the 2 people yesterday who 
independently say that Python is broken because package.os 
hides the "real" os from any module within package. Now you 
want to make it so that a module named os living in a parent 
package hides the "real" os (which, given your desire to be 
able to install as a subpackage of  arbitrary packages is 
simply suicidal).

You might also try explaining to the bunch of (non-newbies) 
who are trying to explain the phenomena that their 
explanations are *wrong*.



- Gordon