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: <module 'sys' (built-in)> 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....
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/3GQXKOXYG4VL4DUCUURKBVKWTHL3LIJL/
Code of Conduct: http://python.org/psf/codeofconduct/
