Add inspect.locate and inspect.resolve #57124
Comments
|
The need to resolve a dotted name to a Python object is spreading in the stdlib: pydoc has locate and resolve, packaging has util.resolve_name, unittest has something else, etc. For the benefit of stdlib maintainers as well as the community, I think such functionality should be exposed publicly by the inspect module. |
merwok
added
stdlib
|
To be a little clearer, this is about dotted import names, not regular dotted names. It is not completely clear to me how this is different from using __import__ but I will believe it is. It something like this is in at least 3 places, +1 on factoring it out to one place. |
|
Sorry if I was unclear; the functions work with a dotted name as a string and resolve it to an object. __import__ works with module, whereas this kind of functions work with mod.name, pkg.mod.name.attr, etc., that is, they combine import and getattr. |
|
In addition, error handling/reporting is not trivial to get right. We’ve had to fix the code in distutils2 and it’s still not quite right (bpo-12703). I opened this report because I’d like to see all stdlib modules use the same functions and I’d prefer people to copy-paste the same robust code for backports. |
|
New changeset 1405df4a1535 by Éric Araujo in branch 'default': |
|
The version in logging.config appears to be doing the same job, but is shorter: def _resolve(name):
"""Resolve a dotted name to a global object."""
name = name.split('.')
used = name.pop(0)
found = __import__(used)
for n in name:
used = used + '.' + n
try:
found = getattr(found, n)
except AttributeError:
__import__(used)
found = getattr(found, n)
return foundThe line "used = used + '.' + n" could of course be improved. |
|
New changeset 5df1065ddb8b by Éric Araujo in branch 'default': |
|
Attaching new patch to address Vinay Sajip's suggestions on Rietveld. Thank you, Vinay. |
|
Something to consider with these functions: it is probably desirable to also support the popular alternate notation which uses an explicit ":" to separate the module name from the reference within the module. For example, setuptools entry points and nose test references both use that format. The alternate notation should be fairly easy to both detect and handle through "name.partition(':')" |
|
Can you provide a couple of examples of that notation? |
entry_points = """
[console_scripts]
pybabel = babel.messages.frontend:main[distutils.commands] [distutils.setup_keywords] [babel.checkers] [babel.extractors] Source: |
|
Another question to consider: is inspect the best place for this? I don't think it is, because (a) It's not really an inspection facility I think it makes more sense for it to be in importlib. Accordingly adding Brett to nosy, for his thoughts. |
|
importlib.util.resolve_name() already exists for resolving an explicit relative import name to an absolute one, so closing this as out of date. |
But that's not what the proposed functionality is for, is it? This covers finding values inside an imported module which can be accessed via a dotted path from the module globals. |
|
Importlib already has importlib.import_module() (since Python 2.7) and that's as far as I'm willing to go for finding a module by name. Anything past that is a getarr() call on the resulting module and thus not worth adding to importlib. |
Okay, fair enough. It's not purely an import function, though partly related to imports. |
|
With the lack of support, I suggest closing this. |
Well, the lack of support is just for adding to importlib. It still seems useful to refactor it out ... just not clear where the best place is. Perhaps pkgutil? It's definitely useful to have in the stdlib in one place. I'll come up with a PR soon. |
|
FTR, Django has a similar helper: from django.utils.module_loading import import_string
ValidationError = import_string('django.core.exceptions.ValidationError')https://docs.djangoproject.com/en/3.0/ref/utils/#django.utils.module_loading.import_string |
|
The regex looks too strict. Python 3 accepts non-ASCII module names. Should existing functions be modified to reuse the new function? |
Would adding the re.U flag be enough, or are you thinking of other possibilities? |
|
To be more precise, one could use ^(?!\d)(\w+)(\.(?!\d)(\w+))* for _DOTTED_WORDS and use the re.U flag when compiling the pattern. That should match any packages where segments start with a letter and continue with alphanumerics. Do you agree? |
|
I reopen the issue to discuss the non-ASCII identifiers. Currently, the code uses [a-z_]\w*, but "é" is a valid Python module name for example: $ echo 'print("here")' > é.py
$ python3 -c 'import é'
hereI'm not sure how to design the regex. I just reported a potential issue ;-) See the PEP-3131 and str.isidentifier() method: |
Did you not look at the PR I added to address this (Unicode chars), with a regex change? I added you as a reviewer. |
|
PR18517 has, likely, a utf-8 dependency. AIX, default latin-1 does not accept the new test. Starting with this merge AIX bot fails with: Traceback (most recent call last):
File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_pkgutil.py", line 249, in test_name_resolution
os.makedirs(d, exist_ok=True)
File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/os.py", line 223, in makedirs
mkdir(name, mode)
UnicodeEncodeError: 'latin-1' codec can't encode characters in position 17-19: ordinal not in range(256)Not completely resolved. |
The test should be modified to skip the current uw value in the loop ("continue") if the filesystem encoding cannot encode the Unicode string (catch UnicodeEncodeError on the makedirs() call). |
|
I am very busy with normal work this week. However I’ll attempt to add a pr with your (Victor”s) suggestion. Sent from my iPhone
|
|
I understand that all known issues are now fixed, so I close the issue. |
|
See bpo-41154 for possible regression introduced by these changes. |
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: