Hi Steven, That makes sense to me: I wrote https://github.com/python/cpython/pull/24353 to exclude sub-package.
The change removes 12 sub-packages from sys.stdlib_module_names and len(sys.stdlib_module_names) becomes 300 :-) -"concurrent.futures", -"ctypes.macholib", -"distutils.command", -"email.mime", -"ensurepip._bundled", -"lib2to3.fixes", -"lib2to3.pgen2", -"multiprocessing.dummy", -"xml.dom", -"xml.etree", -"xml.parsers", -"xml.sax", With that name, names of sys.stdlib_module_names don't contain "." anymore. So to check if "email.message" is a stdlib module name, exclude the part after the first dot, and check if "email" is in sys.stdlib_module_names. In practice, it is not possible to add a sub-package or a sub-module to a stdlib module, so this limitation (excluding sub-packages and sub-modules) sounds reasonable to me. Victor On Wed, Jan 27, 2021 at 1:09 AM Steven D'Aprano <st...@pearwood.info> wrote: > This descriptive name is *literally incorrect*. By design, it doesn't > list modules. It only lists sub-packages and not sub-modules, to keep > the number of entries more managable. > > (Personally, I don't think an extra hundred or two names makes that much > difference. Its going to be a big list one way or the other.) > > So by the current rules, many stdlib modules are not included and the > name is inaccurate. > > If you're not going to list all the dotted modules of a package, why > distinguish sub-modules from sub-packages? It is confusing and ackward > to have only some dotted modules listed based on the **implementation**. > > (We need a good term for "things you can import that create a module > *object* regardless of whether they are a *module file* or a *package*. > I'm calling them a dotted module for lack of a better name.) > > By the current rules, many stdlib modules are not listed, and you can't > see why unless you know their implementation: > > > * urllib - listed > * urllib.parse - not listed > > * collections - listed > * collections.abc - not listed > > * email - listed > * email.parser - not listed > * email.mime - listed # Surprise! > > > So we have this weird situation where an implementation detail of the > dotted module (whether it is a file `package/module.py` or > `package/module/__init__.py`) determines whether it shows up or not. > > And because the file system structure of a module is not part of its > API, that implementation detail could change without warning. > > I think that either of: > > 1. list *all* package dotted modules regardless of whether they are > implemented as a sub-module or sub-package; > > 2. list *no* package dotted modules, only the top-level package; > > would be better than this inconsistent hybrid of only listing some > dotted modules. > > (Excluding the test modules is fine.) -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UW6F2MRC5RNOLEJJI64BALENK7R7UYA2/ Code of Conduct: http://python.org/psf/codeofconduct/
