On Tue, Jan 26, 2021 at 12:08:03PM -0800, Brett Cannon wrote:
> On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou <antoine@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-leave@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/
> On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou <antoine@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-leave@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/