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.

classification
Title: Package cache doesn't cache packages with overlapping sys.path entries
Type: behavior Stage: resolved
Components: Versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 2.7, Python 2.6
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: daniel.wagner-hall, pitrou, r.david.murray
Priority: normal Keywords:

Created on 2012-09-04 22:59 by daniel.wagner-hall, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
packageissue.tgz daniel.wagner-hall, 2012-09-04 22:59
Messages (5)
msg169842 - (view) Author: Daniel Wagner-Hall (daniel.wagner-hall) * Date: 2012-09-04 22:59
Importing the same module twice should only execute its code once, and should only lead to one copy of the classes defined in the module's file.

If a subdirectory of $PWD is on $PYTHONPATH, and a package is imported both relative to $PWD and relative to that subdirectory, its code is loaded twice, and its classes are defined twice independently.

Downloading the attached file, and running:

mkdir folder
cd folder
tar xf file.tgz
PYTHONPATH=$(pwd)/package python main.py

should print import once, but does print import twice.
msg169846 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-04 23:45
Unless I misunderstand you, you are importing the module using two different names, so loading it twice would be the correct behavior.  That is, 'foo.bar.baz' is a different thing from 'bar.baz' from Python's point of view.
msg169847 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-09-04 23:47
Agreed, I don't think this is a bug.
msg169848 - (view) Author: Daniel Wagner-Hall (daniel.wagner-hall) * Date: 2012-09-04 23:57
That is indeed the behaviour I'm talking about.

In particular I came across this where two libraries imported an exception type using different sys.path traversals, which both led to the same file, and a try-catch didn't catch the exception because it had a different type (even though it had been defined by the same file).  This was a pretty horrible bug to track down.

That said, messing with sys.path is pretty ugly, so I can see why this would be intentional, but it still feels like the the types of the same class, defined by the same file, should be equal.
msg169849 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-09-05 00:06
It isn't the file things are defined in that matters, it is how the module object is named.  As I said, foo.bar.baz and bar.baz are different objects from Python's point of view, as you found out.
History
Date User Action Args
2022-04-11 14:57:35adminsetgithub: 60068
2012-09-05 00:06:44r.david.murraysetstatus: open -> closed
resolution: not a bug
messages: + msg169849

stage: resolved
2012-09-04 23:57:32daniel.wagner-hallsetmessages: + msg169848
2012-09-04 23:47:42pitrousetnosy: + pitrou
messages: + msg169847
2012-09-04 23:45:13r.david.murraysetnosy: + r.david.murray
messages: + msg169846
2012-09-04 22:59:34daniel.wagner-hallcreate