This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Improve ambiguous docstrings in pkgutil
Type: enhancement Stage:
Components: Documentation Versions: Python 3.11, Python 3.10, Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: barneygale, docs@python, khock, slateny
Priority: normal Keywords: easy

Created on 2021-12-05 18:56 by khock, last changed 2022-04-11 14:59 by admin.

Messages (7)
msg407727 - (view) Author: Kevin Hock (khock) Date: 2021-12-05 18:56
# Issue

If you search for "list of paths" in https://github.com/KevinHock/cpython/blob/main/Lib/pkgutil.py

A lot of people mistake this as `PosixPath`. You can see an example here: https://github.com/duo-labs/parliament/pull/207 that references other OSS repositories.

# Solution

We can
- Change the wording. e.g. "list of strings of the paths" or some variation of that.

and perhaps additionally

- Throw a ValueError similar to: https://github.com/python/cpython/blob/628abe4463ed40cd54ca952a2b4cc2d6e74073f7/Lib/pkgutil.py#L122
msg413883 - (view) Author: Stanley (slateny) * Date: 2022-02-24 06:46
Could you expand a bit on why 'list of paths' in pkgutil is understood by default to be 'list of PosixPath paths'? I would interpret it by default to be string paths if I saw it somewhere without context
msg413933 - (view) Author: Kevin Hock (khock) Date: 2022-02-24 17:54
At best it is ambiguous, with the class being confused with Str being called Path. Looking up "AttributeError: 'PosixPath' object has no attribute 'startswith'" gives a lot of results for similar issues, so I think the wording could be improved.
msg413957 - (view) Author: Stanley (slateny) * Date: 2022-02-25 03:15
While it is ambiguous, when there's a path parameter I would default it to string unless otherwise specified. Maybe instead a note could be put in the Pathlib doc noting functions that accept path arguments might not accept Path objects?
msg414076 - (view) Author: Barney Gale (barneygale) * Date: 2022-02-26 06:21
Should pkgutil call os.fspath() in this case?
msg414212 - (view) Author: Kevin Hock (khock) Date: 2022-02-28 17:43
> Maybe instead a note could be put in the Pathlib doc noting functions that accept path arguments might not accept Path objects?

My concern with that is that someone using `pkgutil` wouldn't see it. However, I can see the argument that fixing the 'source' is better than each use. I'm not sure how wide-spread these kind of issues are to weigh in on how many 'uses' there are. If that makes sense.

>Should pkgutil call os.fspath() in this case?

I really like that idea. (I haven't contributed to CPython before, so I'll let someone else weigh in on if that is standard practice.)
msg414230 - (view) Author: Stanley (slateny) * Date: 2022-03-01 01:22
I feel like there might be some backwards compatibility issues if pkgutil wraps it like that, but similarly I'm not at all familiar with how common the package is used and whether it'd be fine to make that change, so I'll also differ judgement here.
History
Date User Action Args
2022-04-11 14:59:53adminsetgithub: 90149
2022-03-01 01:22:11slatenysetmessages: + msg414230
2022-02-28 17:43:13khocksetmessages: + msg414212
2022-02-26 06:21:53barneygalesetnosy: + barneygale
messages: + msg414076
2022-02-25 03:15:31slatenysetmessages: + msg413957
2022-02-24 17:54:19khocksetmessages: + msg413933
2022-02-24 06:46:30slatenysetnosy: + slateny
messages: + msg413883
2022-01-14 11:49:08iritkatrielsetkeywords: + easy
versions: - Python 3.6, Python 3.7, Python 3.8
2021-12-05 18:56:47khockcreate