[ python-Bugs-935117 ] pkgutil doesn't understand case-senseless
filesystems
SourceForge.net
noreply at sourceforge.net
Fri Jul 2 12:25:08 EDT 2004
Bugs item #935117, was opened at 2004-04-14 14:35
Message generated for change (Comment added) made by fdrake
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=935117&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pkgutil doesn't understand case-senseless filesystems
Initial Comment:
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.
----------------------------------------------------------------------
>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-07-02 12:25
Message:
Logged In: YES
user_id=3066
Assigned to me since I intend to make this work in the end.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-06-19 17:26
Message:
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.
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-04-14 14:38
Message:
Logged In: YES
user_id=3066
Argh! Here's the tree again, since comments don't get
screwed up the same way initial reports are:
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
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=935117&group_id=5470
More information about the Python-bugs-list
mailing list