Jonathan Fine wrote:
Suppose we had a similar 'which' command in Python. It wouldn't by itself stop things going wrong. But when they do go wrong, it might help diagnose the problem.
This thread got me thinking about something exactly along these lines. It looks like the needed information is provided by, e.g., inspect.getfile, which on quick testing works for both modules and for objects imported from modules. For builtins, a TypeError is raised:
inspect.getfile(sys) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Users\Brian\AppData\Local\Programs\Python\Python37\Lib\inspect.py", line 647, in getfile raise TypeError('{!r} is a built-in module'.format(object)) TypeError:
is a built-in module
For nonbuiltins, the full path to the relevant .py is returned:
inspect.getfile(inspect) 'C:\\...\\Python\\Python37\\Lib\\inspect.py'
I'm sure there are other ways of inferring this, too. So, I guess the first question is whether it's worth actually implementing something into Python to make surfacing this information easier, or more automatic, or whatever -- or if it's really just a marketing campaign to make people more aware of, e.g., `inspect.getfile()` as a handy import debugging tool. From there is the thornier question of whether implementing a feature to enable active filtering of imports based on location/category is a good idea or not. It seems like there's enough variability in installation locations/contexts/etc. that coming up with a consistent set of filtering rules would be a piece of a nightmare....