# 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: duo-labs/parliament#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:

  cpython/Lib/pkgutil.py

  Line 122 in 628abe4

  elif isinstance(path, str):

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

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.

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?

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

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

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.

Shouldn't this be closed? If not, I'd like to work on it.

Shouldn't this be closed? If not, I'd like to work on it.

@safwansamsudeen I think you can work on it, just adding a note to the doc string saying that the path needs to be an str and/or adding a type check should be enough instead of converting a PosixPath to a string.