Problematic behavior of the import statement when several module files have the same name.

2005-03-09 Thread Xif
Hello Everyone!

Here's a problem with relative imports:

Suppose I have a package called some_package (in a separate directory
included in the PYTHONPATH, with an __init__.py file etc.)

This package has a module inside the directory, called "database", and
therefore  residing in the file some_package/database.py.

Now, what if there's another module, for example inside the
site-packages directory, with the same file name (i.e. database.py)?

We have a problem. Since although these modules have different absolute
names ("some_package.database" for the first module, and just
"database" for the second), when I try to do

import database

from inside some_package, it first of all tries to find the matching
file in the some_package directory (i.e. do a relative import). Since
it first checks the some_package directory, and finds database.py
there,

import database

in fact imports the module with the absolute name
some_package.database.

This is problemat on two levels:

1) It is surprising and undesirable that "import database" in effect
may do two completely different things ("import some_package.database"
or "import database") depending on an external, unpredictable factor:
the existence of a database.py file inside the some_package directory.

2) It effectively prevents you from naming a module inside a package
with the same name of any module in the "root" PYTHONPATH directories.
In my example, there's no sane way I can see of having
some_package.database if there's already a database module (database.py
file) in any PYTHONPATH directory.

Are my observations correct?  Is there something I ignored?  Should
this be posted somewhere else?

Your comments would be appreciated.

Xif

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: How do you control _all_ items added to a list?

2005-02-28 Thread Xif
Quoting Fuzzyman:

"If you subclass list then you will need to override all methods that
can set items."


Overiding all those methods is too much of an effort. I don't really
need them.

I'll just have an object that uses a list internally, and define only
the two methods I really need: extend() and getItems().

That way I retain full control over what goes into the private
obj._list, without the superfluous work of overriding all those methods
I don't really need.

Thanks for your help,
Xif

-- 
http://mail.python.org/mailman/listinfo/python-list


How do you control _all_ items added to a list?

2005-02-28 Thread Xif
Hi

I want to have control over all items added to a list.

The first attempt was to subclass list and override its .append()
method.

Problem is, there are plenty of other ways the list can have items
added to it - e.g. extend, insert - and theyr'e not at all affected by
the changes I made to append.

Is there some "base" item-adding method that all other item-adding
methods use, so I can override it and have the changes affect all
item-adding functions?

Thanks,
Xif

-- 
http://mail.python.org/mailman/listinfo/python-list