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

[Huaiyu Zhu]

On Wed, 28 Jun 2000 15:16:11 -0700, Sean Blakey <sblakey at freei.com> wrote:

>OK, I think I see what you mean.  You are objecting to the way that python
>searches first for modules in the local directory before searching the normal
>PYTHONPATH, correct?
>
>For example, If you have a script string.py and foo.py in your local directory
>and foo has an "import string" statement, you want foo to import string from the
>standard library instead of from your string.py script.

That is right. If this can't be remedied the package namespaces are
essentially flat.


>It seems to me that you are expecting python too read your mind about where you
>want the modules imported from.  I believe python's behavior makes sens for most
>cases.

Nothing like that.  I can tell python my mind.  I just need the syntax for
doing so.  If you read my explanation, you'll see that this situation is
quite common.  After all, providing heirarchical name space for module names
is the very reason we need packages. Right?

On Unix you can say /bin/sh and expect the correct sh to be used whatever
your PATH and whatever other sh sits in different directories, including
current directory.  My little proposal in the original post was intedend to
add this ability to Python as well.


>If you don't want python to search the current directory for imports, there is a
>very simple solution: put this snippet above all of your other imports:
>import sys
>sys.path.remove('.')
>

This might be fine for personal use.  But I'm developing a general package
that is being used by many people.  I don't think it's safe to fiddle with
that.  And as I said, the functionality of packages can not (and absolutely
should not) depend on the order of sys.path.  Otherwise packages expecting
different ordering of sys.path cannot be used together.


Huaiyu
-- 
Huaiyu Zhu                       hzhu at users.sourceforge.net
Matrix for Python Project        http://MatPy.sourceforge.net