On Tue, Jan 26, 2021 at 12:08:03PM -0800, Brett Cannon wrote:
> On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou <anto...@python.org> wrote:

[...]
> > Disagreed.  This is niche enough that it warrants a long but explicit
> > name, rather than some ambiguous shortcut.
> >
> 
> I agree w/ Antoine that a more descriptive name for such a niche (but
> useful!) attribute makes sense.

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.)



-- 
Steve
_______________________________________________
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/GNOAP4TVTHIUKE2GUGZWV6HNVE37KU4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to