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.

Title: -v command line option is broken
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.3
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, kristjan.jonsson, loewis
Priority: normal Keywords:

Created on 2012-05-31 14:40 by kristjan.jonsson, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (7)
msg162002 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2012-05-31 14:40
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/

we now get:
import 'textwrap' # <_frozen_importlib.SourceFileLoader object at 0x0000000002E14438>

I don't even know what a _frozen_importlib.SourceFileLoader is.
msg162003 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-05-31 14:49
for the source of SourceFileLoader.
msg162006 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2012-05-31 15:20
Yes, I found that.  The line in question is, however, this:
     _verbose_message('import {!r} # {!r}', name, loader)

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.
msg162008 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-05-31 15:37
The information is still there, just in a different output line (i.e. 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).
msg162009 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-05-31 15:38
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.
msg162010 - (view) Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) Date: 2012-05-31 15:50
Oh dear, silly me.
I misunderstood the point of -v _and_ misunderstood the output of 2.7 I was quoting.
I was looking for a way to find out where the import originated from, not which file would be imported as a result.

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.
msg162012 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-05-31 16:50
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.
Date User Action Args
2022-04-11 14:57:31adminsetgithub: 59175
2012-05-31 16:50:13brett.cannonsetmessages: + msg162012
2012-05-31 15:50:03kristjan.jonssonsetstatus: pending -> closed
resolution: not a bug
messages: + msg162010
2012-05-31 15:38:14brett.cannonsetstatus: open -> pending

messages: + msg162009
2012-05-31 15:37:32brett.cannonsetnosy: + brett.cannon
messages: + msg162008
2012-05-31 15:20:36kristjan.jonssonsetmessages: + msg162006
2012-05-31 14:49:42loewissetnosy: + loewis
messages: + msg162003
2012-05-31 14:40:42kristjan.jonssoncreate