New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make importlib.machinery class handle os.PathLike path #74433
Comments
Several importlib.machinery class has 'path' attribute, make it possible to handle os.PathLike. |
Relate to bpo-29448 |
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? |
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 (https://github.com/python/cpython/blob/master/Modules/posixmodule.c#L12099). 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. |
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? |
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:
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. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: