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
-v command line option is broken #59175
Comments
Using the -v command line option to diagnose import problem is no longer useful. In stead of lines like this in version 2.7: import UserDict # from D:\p4\games\branches\development\MAIN\eve\dust\tool\bin/../../../../carbon/src/stackless/Lib/UserDict.py we now get: I don't even know what a _frozen_importlib.SourceFileLoader is. |
See http://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap.py |
Yes, I found that. The line in question is, however, this: Unfortunately, I see no way to get at the line from which the import occurred here. The loader itself is not useful for that. Perhaps the author of importlib knows more, e.g. whether the feature to know whence an import originates is useful or has been dropped. |
The information is still there, just in a different output line (i.e. http://hg.python.org/cpython/file/c7b16e2be71a/Lib/importlib/_bootstrap.py#l735 outputs the same info, just on its own line). I couldn't keep the old format as the code has been shifted around enough compared to how import.c was structured that reproducing the same output would have required a code refactor and contortion that wasn't worth it. I did my best to make sure no useful data was left out (and actually there is more since the loader is now also stated so you always have that info instead of only what Python's included loaders provide). |
I am setting this as pending since I consider the total output acceptable, but if Kristján has specific issues he wants to bring up or change he still can. |
Oh dear, silly me. Import errors, along with pickling errors, are some of the most annoying ones to debug, because they tend to require so much detective work. Ok, I'll close this then. Sorry about the noise. |
Not a problem. =) If you want to know where an import originated from, you can probably do something as simple as overload builtins.__import__ with a version that does a quick stack look to see where the previous call is coming from. |
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: