From gmcm@hypernet.com  Thu Jun 29 18:08:27 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Thu, 29 Jun 2000 13:08:27 -0400
Subject: [Import-sig] Re: (Serious?) package namespace problem (and a proposal)
References: <slrn8lknve.1v9.hzhu@rocket.knowledgetrack.com> <395A66C5.E9AC4F3E@roguewave.com> <slrn8lkta6.1v9.hzhu@rocket.knowledgetrack.com> <20000628151611.A2972@freei.com> <8F61C6D29gmcmhypernetcom@199.171.54.194> <ffcmlsc6p4lqohdd6tequdu918l0temns4@4ax.com> <395B6027.B47094CA@letterror.com>
Message-ID: <1249823989-44806428@hypernet.com>

Just van Rossum wrote: 

><silly-proposal>
>If relative imports as we know them are shot in the head, an
>alternative spelling for relative imports could be invented.
>Eg. with a leading period:
>
>import .some.submodule
></silly-proposal>

The import SIG is comatose, but not dead.

I can see the usefulness of relative imports, and (very) infrequently, use 
them myself. But they have quite a few problems:
 - hiding modules / packages outside the current package
 - create the possibility that an app will have 2 instances of a module, 
thus screwing up module globals (and very hard to debug)
 - they slow down normal imports 

Their main feature is "ease of use", which can be pejoratively cast as 
"programmer laziness". 

not-that-I'd-ever-say-such-a-thing-ly y'rs

- Gordon


From mal@lemburg.com  Fri Jun 30 10:12:26 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 11:12:26 +0200
Subject: [Import-sig] Re: (Serious?) package namespace problem (and a
 proposal)
References: <slrn8lknve.1v9.hzhu@rocket.knowledgetrack.com> <395A66C5.E9AC4F3E@roguewave.com> <slrn8lkta6.1v9.hzhu@rocket.knowledgetrack.com> <20000628151611.A2972@freei.com> <8F61C6D29gmcmhypernetcom@199.171.54.194> <ffcmlsc6p4lqohdd6tequdu918l0temns4@4ax.com> <395B6027.B47094CA@letterror.com> <1249823989-44806428@hypernet.com>
Message-ID: <395C647A.7BA1C224@lemburg.com>

Gordon McMillan wrote:
> 
> Just van Rossum wrote:
> 
> ><silly-proposal>
> >If relative imports as we know them are shot in the head, an
> >alternative spelling for relative imports could be invented.
> >Eg. with a leading period:
> >
> >import .some.submodule
> ></silly-proposal>
> 
> The import SIG is comatose, but not dead.
> 
> I can see the usefulness of relative imports, and (very) infrequently, use
> them myself. But they have quite a few problems:
>  - hiding modules / packages outside the current package
>  - create the possibility that an app will have 2 instances of a module,
> thus screwing up module globals (and very hard to debug)
>  - they slow down normal imports
> 
> Their main feature is "ease of use", which can be pejoratively cast as
> "programmer laziness".

No no no... the feature can be put to clever use *within*
packages. If you always have to specify the absolute path
to the modules, you will have a hard time moving packages
under new umbrella packages -- something which gets done every
now and then. Not having relative imports then causes
a lot of breakage.

BTW, you will see this happen when I publish my new mx
extension set. (I will provide a hack to ease the pain, though.)

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


From gmcm@hypernet.com  Fri Jun 30 12:51:22 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Fri, 30 Jun 2000 07:51:22 -0400
Subject: [Import-sig] Re: (Serious?) package namespace problem (and a  proposal)
In-Reply-To: <395C647A.7BA1C224@lemburg.com>
Message-ID: <1249756551-48863055@hypernet.com>

M.-A. Lemburg wrote:

> Gordon McMillan wrote:
> > 
> > Just van Rossum wrote:
> > 
> > ><silly-proposal>

[ to spell relative imports differently than absolute imports - 
Just's syntax may have been silly, but the idea is not ]

> > ></silly-proposal>

> > I can see the usefulness of relative imports, and (very)
> > infrequently, use them myself. But they have quite a few
> > problems:
> >  - hiding modules / packages outside the current package
> >  - create the possibility that an app will have 2 instances of
> >  a module,
> > thus screwing up module globals (and very hard to debug)
> >  - they slow down normal imports
> > 
> > Their main feature is "ease of use", which can be pejoratively
> > cast as "programmer laziness".
> 
> No no no... the feature can be put to clever use *within*
> packages. If you always have to specify the absolute path
> to the modules, you will have a hard time moving packages
> under new umbrella packages -- something which gets done every
> now and then. Not having relative imports then causes a lot of
> breakage.

And how does anything you've said contradict (as in "No no 
no") anything I said?

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?

When "import mxDateTime" doesn't throw an exception, 
people for some reason expect to be able to *use* 
mxDateTime.

clever-is-often-another-name-for-stupid-ly y'rs


- Gordon


From mal@lemburg.com  Fri Jun 30 14:36:14 2000
From: mal@lemburg.com (M.-A. Lemburg)
Date: Fri, 30 Jun 2000 15:36:14 +0200
Subject: [Import-sig] Re: (Serious?) package namespace problem (and a
 proposal)
References: <1249756551-48863055@hypernet.com>
Message-ID: <395CA24E.BD56E9D8@lemburg.com>

Gordon McMillan about relative imports:
> 
> > > Their main feature is "ease of use", which can be pejoratively
> > > cast as "programmer laziness".
> >
> > No no no... the feature can be put to clever use *within*
> > packages. If you always have to specify the absolute path
> > to the modules, you will have a hard time moving packages
> > under new umbrella packages -- something which gets done every
> > now and then. Not having relative imports then causes a lot of
> > breakage.
> 
> And how does anything you've said contradict (as in "No no
> no") anything I said?

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.

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).

> 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.

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

> 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.

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.

The proposal was tossed around a few times and nothing
happened. Perhaps I should look into the new imputil
design and recheck whether I can add something there...

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


From gmcm@hypernet.com  Fri Jun 30 16:45:39 2000
From: gmcm@hypernet.com (Gordon McMillan)
Date: Fri, 30 Jun 2000 11:45:39 -0400
Subject: [Import-sig] Re: (Serious?) package namespace problem (and a   proposal)
In-Reply-To: <395CA24E.BD56E9D8@lemburg.com>
Message-ID: <1249742498-49708905@hypernet.com>

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