-
-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
pdb mangles sys.path when run with -P or ._pth #99367
Comments
Hi @cwalther , do you still work on this? You can make a PR with a regression test. If you don't want to work on the test, I can make the PR and list you as co-author. |
Thank you for the feedback! Sure, I can try to make a test and submit a PR. I am not currently working on CPython however, and it will probably take a few weeks until I have time to set up a development environment and figure out how the testing works. So, if you can do it more quickly than that, that would be nice. But I have no urgent need for a fix. |
Don't worry about that, it's not a super complicated change. I can do it and list you as the co-author. |
Co-authored-by: Christian Walther <[email protected]>
This is fixed. |
…ython#111762) Co-authored-by: Christian Walther <[email protected]>
…ython#111762) Co-authored-by: Christian Walther <[email protected]>
Bug report
When running a script,
pdb
indiscriminately replacessys.path[0]
, which it assumes to be the path wherepdb
itself was found, with the path where the script was found. That assumption may not be correct: it is not when the interpreter runs in “safe path” mode due to a-P
command line option or the presence of a._pth
file. In that casesys.path[0]
may point to the standard library, and overwriting it may break the script’s ability to import standard library modules.This is easily reproduced in the embeddable package for Windows, which has the standard library in python311.zip, refers to it in
sys.path[0]
, and has a python311._pth file, but should also be reproducible (using-P
) on other platforms in any other installation that finds the standard library insys.path[0]
. (This is not the case in a standard installation for Windows, which has'…\\python311.zip'
insys.path[0]
, but that file doesn’t actually exist and the standard library is located in files inLib/
and is found through later entries insys.path
.)Steps to reproduce
script.py:
Actual result
Expected result
It seems to me this could be fixed as follows (which is what I used to get the “expected result”), or maybe by comparing
sys.path[0]
with__file__
to check the assumption directly:Any opinions, should I make a PR with that?
Your environment
Linked PRs
The text was updated successfully, but these errors were encountered: