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.

Title: Make importlib.machinery class handle os.PathLike path
Type: Stage:
Components: Library (Lib) Versions: Python 3.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, eric.snow, louielu, ncoghlan, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-05-03 07:42 by louielu, last changed 2022-04-11 14:58 by admin.

Pull Requests
URL Status Linked Edit
PR 1422 closed louielu, 2017-05-03 07:45
Messages (6)
msg292856 - (view) Author: Louie Lu (louielu) * Date: 2017-05-03 07:42
Several importlib.machinery class has 'path' attribute, make it possible to handle os.PathLike.
msg292857 - (view) Author: Louie Lu (louielu) * Date: 2017-05-03 07:43
Relate to #29448
msg292899 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-03 13:08
I'm not sure it's a good idea. FileLoader, FileFinder, and other classes usually are a part of import machinery, they can have other restrictions on path type than general filesystem related functions. This change has a non-zero cost, it complicates the code and makes it slower. Do you have a use case for using these classes with a path different from None or str?
msg292926 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2017-05-03 16:50
The classes mentioned actually require that the path exist on the file system so there's no extra restrictions. As for cost, it's pretty cheap as a call to _os.fspath() is written in C and does an immediate type-check for str or bytes for the common-case ( These classes are also instantiated once typically and then cached so the cost is only paid once per object.

As for use-cases, I've seen people directly instantiate these classes in user code and so supporting paths in a universal way like the rest of the stdlib would be good for consistency.
msg293041 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-05-05 04:48
If the path attribute can be None or list it looks to me that it isn't a filesystem path, and it may be incorrect to use os.fspath() with it. How this attribute is used? What wrong if left it a pathlib.Path?
msg293045 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-05-05 06:20
FileFinder only handles a single directory, and FileLoader only handles a single file, so their "path" attributes are paths in the "fspath" sense, rather than the "sys.path" or "PathFinder" sense.

Perhaps it would be worth the hassle of migrating to "fspath" as the attribute and parameter names here?

The attribute can be renamed without breaking backwards compatibility by also adding a "path" property that manipulates the renamed "fspath" attribute.

Renaming the parameters would be a bit trickier, since we would need to allow the parameter to be supplied under either name for at least 3.7, so we'd need to do something like:

1. Remove the current positional-or-keyword "path" parameter
2. Add keyword-only "path" and "fspath" parameters that default to None
3. Accept arbitrary additional positional arguments (which is already the case for FileFinder)
4. If both of the new keyword-only parameters are None, then extract "fspath" from the tuple of positional parameters (i.e. by doing "fspath, *loader_details loader_details" in FileFinder, and "fspath, * = args" in the FileLoader classes

At a documentation level, this would just be described as the parameter name being "fspath", and a versionchanged note for 3.7 saying that the parameter name changed from "path" to "fspath" and the old "path' name is still supported as a keyword argument for backwards compatibility reasons.

If we actively deprecated the old names, then the deprecation warnings would live in the access function definitions for the "path" attribute, and in the case where the "path" keyword argument was non-None for the renamed parameters.
Date User Action Args
2022-04-11 14:58:46adminsetgithub: 74433
2017-05-05 06:20:02ncoghlansetmessages: + msg293045
2017-05-05 04:48:38serhiy.storchakasetmessages: + msg293041
2017-05-03 16:50:19brett.cannonsetmessages: + msg292926
2017-05-03 13:08:03serhiy.storchakasetnosy: + eric.snow, serhiy.storchaka, ncoghlan
messages: + msg292899
2017-05-03 07:45:32louielusetpull_requests: + pull_request1528
2017-05-03 07:45:10louielusetnosy: + brett.cannon
components: + Library (Lib)
2017-05-03 07:43:10louielusetmessages: + msg292857
2017-05-03 07:42:38louielucreate