New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkgutil doesn't understand case-senseless filesystems #40152
Comments
The pkgutil.extend_path() function doesn't understand Consider this tree in a filesystem: d1/ sys.path contains d1/, d2/, d3/, in that order. After the call to extend_path() in d1/foo/init.py, pkgutil.extend_path() should exercise the same care and |
Logged In: YES Attaching a pure-Python case_ok() "building block" that |
Logged In: YES 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. |
Antoine: I agree programmers shouldn't try to create situations like this. Consider however an application assembled using a build tool like Now, further development on the application may cause a 3rd-party So I think the original use case stands, and may even be more important This also suggests that developers should check for the existence of (I'm disassociating msg20510, since roundup doesn't screw up the tree in |
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?) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: