(Serious?) package namespace problem (and a proposal)

[Gordon McMillan]

Huaiyu Zhu wrote: 

>On 28 Jun 2000 22:51:18 GMT, Gordon McMillan <gmcm at hypernet.com> wrote:

>>Besides avoiding using the same name, you could make the top level a 
>>package, then python.BBB.AAA could import python.AAA and it would be 
>>completely unambiguous. Which is a good reason to avoid relative
>>imports - they are by nature ambiguous.
>
>I don't follow you here.  Both AAA and BBB are packages.   In fact they
>are 
>
>python/
>   AAA/
>      __init__.py
>   BBB/
>      __init__.py
>      aaa.py

I meant
 python/
   __init__.py
   AAA/
   ...

In other words, put a package around the whole thing.

But your real problem looks like this:

Gnuplot/
  __init__.py
  Gnuplot.py

MatPy/
  __init__.py
  gnuplot.py

You are being bitten by (1) case insensitivity of Windows and (2) relative 
imports.

[Incidentally. "from Gnuplot import Gnuplot" will *not* try to import 
itself - it could fail because it finds the module Gnuplot before it finds 
the package Gnuplot (this is the relative import problem), or because it 
finds (on Windows) the gnuplot module instead (both problems).]

Quite simply, the authors of Gnuplot are asking for trouble by having a 
package and a module within it with the same name. You are asking for 
trouble by having a module with the same (according to Windows) name as a 
package you want access to.

But the situation is not *quite* as bad as you say. That is:

AA/
 __init__.py
 snarf.py
BB/
 __init__.py
 snarf.py

presents no problem at all, (unless someone uses "from ... import *" which 
can cause name clashes no matter what you do). So we're not talking about a 
"flat" namespace. Just a tricky one <wink>.

>My question is exactly how to make imports absolute instead of relative.

You can't avoid the fact that Python will first try a relative import.

>>>Although it is not advisable to put '.' in path, especially at front,
>>>a lot of people actually do. And the functionality of a package should
>>>not depend on this detail.  Otherwise what happens if one imports
>>>several packages each expecting a different ordering of sys.path?
>>
>>Actually it is very useful, since it allows you to have a script have
>>some private support modules that don't clutter up sys.path for other
>>scripts. 
>
>Hmm, what is useful?  Having '.' in path or allowing packages to demand
>different content of path?  Yes I'd agree to the former (but it's biting
>me now) but I don't see the latter.

No, it's not biting you. That would bite you when you were in Gnuplot/ and 
wrote "from Gnuplot import Gnuplot". You are being bitten by the fact that 
Python *always* looks first in the current package before looking at 
sys.path, (in combination with Windows...).


Lets say you have a (gag) 2,000 line module: foo.py. To speed things up 
(avoid the compile), you write a 2nd script:
------
import foo
foo.main()
------

You shouldn't have to add the directory this is in to PYTHONPATH for this 
to work. (This being why "." *should* be on the path.)

>>You could use Greg Stein's imputils, but in this case just packagizing
>>the whole thing is a more straightforward solution.
>>
>
>Where can I find it?  

http://www.lyra.org/greg/python/