Some design questions:

• Why is the dots-only form "deprecated'?
• Why does the dots-only form not support traversing more than one deep? ("mypkg.mymod.MyClass.my_constructor" will fail to resolve)

I would also comment that requiring the name parts to be valid Python names isn't technically required and adds complexity, although I expect situations where it's a hindrance are few and far between.

Why is the dots-only form "deprecated"?

The word "deprecate" isn't used anywhere. The reason for preferring the new form is given in the documentation.

Why does the dots-only form not support traversing more than one deep? ("mypkg.mymod.MyClass.my_constructor" will fail to resolve)

On what do you base this assertion? For example, logging.handlers.SysLogHandler.LOG_ALERT resolves correctly. I'll update the tests to confirm this.

I would also comment that requiring the name parts to be valid Python names isn't technically required and adds complexity

I don't find the current implementation too complex, and generally attributes are Python identifiers (though of course one might be able to get around that by overriding __getattr__ / __getattribute__) it wouldn't be considered good practice to have attributes which don't meet this constraint.

I would also comment that requiring the name parts to be valid Python names isn't technically required and adds complexity,

For comparison, here are other implementations:

• https://docs.djangoproject.com/en/3.0/_modules/django/utils/module_loading/#import_string Django’s import_string is more limited that resolve_name
• https://github.com/Pylons/pyramid/blob/cc396692d82441f8142fb14041542ebd2dad6f0a/src/pyramid/path.py#L356 Pyramid’s maybe_dotted supports both : and . separators between module and object, but is more complex (the source is, not the usage, in a Pyramid app we only need to call config.maybe_dotted("mod.sub.CoolClass")).

I think that Vinay’s solution using a regex has a nice balance of checking validity without the performance hit of calling for example part.isidentifier().

Codecov Report

Merging #18310 into master will decrease coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #18310      +/-   ##
==========================================
- Coverage   82.20%   82.12%   -0.09%     
==========================================
  Files        1957     1955       -2     
  Lines      588968   584020    -4948     
  Branches    44401    44456      +55     
==========================================
- Hits       484160   479607    -4553     
+ Misses      95153    94767     -386     
+ Partials     9655     9646       -9     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78c7183...0c922dd. Read the comment docs.

I notice that module. is not supported (rightly!), but module: is; is that something officially supported by setuptools’ entry points / other resolve implementations?

Will you update pydoc and other modules to use this new function in a separate PR?

module: is; is that something officially supported by setuptools’ entry points / other resolve implementations?

Not as far as I know, because it doesn't especially make sense for entry points. It seemed reasonable to support this use case, and no reason not to allow it (although not useful for entry points, it could be useful in other contexts).

Will you update pydoc and other modules to use this new function in a separate PR?

Yes, and possibly using more than one PR.