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.

Logged In: YES 
user_id=31435

Attaching a pure-Python case_ok() "building block" that 
should be adequate for doing the hard part of this.  It's 
trickier than first appears because Python's case-sensitive 
imports are not sensitive to the case of extensions 
(.py, .pyo, ...) on case-insensitive filesystems.

Logged In: YES 
user_id=3066

Assigned to me since I intend to make this work in the end.

Fred, do you still want to fix the bug?

Perhaps it's just me, but Fred's use case looks horrible.
If you have three packages named "foo", "Foo" and "foo", all of which
reachable through sys.path on a case-insensitive filesystem, I'm not
sure how to expect Python to make sense out of the situation.
IMHO, the only reasonable solution is to fix the package names...

Antoine: I agree programmers shouldn't try to create situations like this.

Consider however an application assembled using a build tool like
zc.buildout, which installs each package into a separate installation
location (based on setuptools and easy_install).  If the application
uses several packages from the "foo" namespace (to keep with the
original names from the report), there will be directories matching the
first and third packages from the example.

Now, further development on the application may cause a 3rd-party
package named Foo to be used.  This name is not the application
programmer's to select, and the volume of code from the "foo" namespace
may be too large to modify; it may represent 3rd party code (for
example, the "zope" namespace package contains many widely used
examples; if used at all, many are likely to be used).

So I think the original use case stands, and may even be more important
than ever given the widespread use of "namespace" packages.

This also suggests that developers should check for the existence of
packages of similar name before releasing code, in order to avoid this
situation.

(I'm disassociating msg20510, since roundup doesn't screw up the tree in
the original report, so that message no longer adds anything useful.)

With the advent of implicit namespace packages in 3.3, I don’t know if anything in pkgutil will be done for this use case.

(BTW is it normal that pkgutil.extend_path is not at least doc-deprecated?)