This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author fdrake
Recipients
Date 2004-04-14.18:35:19
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
The pkgutil.extend_path() function doesn't understand
case-senseless filesystems the way Python's import
does, but it should.  On a case-insensitive filesystem,
a directory that matches the package name in spelling
but not case can be mistakenly added to a package by
extend_path(); this can cause differently-named
packages to be mistakenly merged and allow unrelated
code to shadow code in a secondary component of a
package (where secondary means something other than the
first directory found that matches the package).

Consider this tree in a filesystem:

d1/
    foo/
        __init__.py     # this calls pkgutil.extend_path()
        module.py      # imports module "foo.something"
d2/
    Foo/
        __init__.py     # an unrelated package
        something.py
d3/
    foo/
        __init__.py
        something.py

sys.path contains d1/, d2/, d3/, in that order.

After the call to extend_path() in d1/foo/__init__.py,
foo.__path__ will contain d1/foo/, d2/Foo/, d3/foo/ (in
that order), and foo/module.py will get
d2/Foo/something.py when it imports foo.something. 
What's intended is that it get d3/foo/something.py; on
a case-sensitive filesystem, that's what would have
happened.

pkgutil.extend_path() should exercise the same care and
check the same constraints as Python's import.
History
Date User Action Args
2007-08-23 14:20:57adminlinkissue935117 messages
2007-08-23 14:20:57admincreate