You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
User subclasses of pathlib.PurePath are os.PathLike #106037
In Python 3.12 we've made pathlib.PurePath subclassable - see #31691.
A significant wrinkle is that subclasses inherit an __fspath__() method, which can lead to unexpected behaviour when these "pure" paths are passed to filesystem APIs:
The with open(readme) as f: line should throw a TypeError, but instead it attempts to open a file called README.md in the current working directory (!). This sort of thing makes subclasses that implement purely virtual filesystems difficult to use safely.
@brettcannon as co-author of PEP 519, your input here would be greatly appreciated!
Though it's not specified as such, I argue that os.PathLike has grown to mean "like a local filesystem path". Functions that accept os.PathLike objects almost always call operating system APIs on their paths. There are notable exceptions (like os.path.join()) that perform only lexical work, but they're in a pretty small minority. The result is that open() etc "work", even on path objects that represent non-local paths such as S3 keys.
PurePosixPath and PureWindowsPath instances and subclasses have always been path-like, so we can't change those. PurePath instances are impossible to create. PurePath subclasses have just become possible in 3.12, which is where I propose making this change. What do you think?
If the question is, "can I leave __fspath__ off of AbstractPath", then I can see that making sense since it is meant for file systems which is not automatic for something which wants to implement pathlib's API.
Closing this issue - PurePath is already path-like and trying to do funky things in subclasses is probably more surprising than PurePath having __fspath__(). The latter may not be surprising at all depending on how you view PurePath! Alex has pointed me towards a good solution for pathlib.AbstractPath.
Activity
pythonGH-106037: Allow subclasses of `pathlib.PurePath` to opt into `…
barneygale commentedon Jun 23, 2023
@brettcannon as co-author of PEP 519, your input here would be greatly appreciated!
Though it's not specified as such, I argue that
os.PathLikehas grown to mean "like a local filesystem path". Functions that acceptos.PathLikeobjects almost always call operating system APIs on their paths. There are notable exceptions (likeos.path.join()) that perform only lexical work, but they're in a pretty small minority. The result is thatopen()etc "work", even on path objects that represent non-local paths such as S3 keys.PurePosixPathandPureWindowsPathinstances and subclasses have always been path-like, so we can't change those.PurePathinstances are impossible to create.PurePathsubclasses have just become possible in 3.12, which is where I propose making this change. What do you think?brettcannon commentedon Jun 23, 2023
If the question is, "can I leave
__fspath__off ofAbstractPath", then I can see that making sense since it is meant for file systems which is not automatic for something which wants to implementpathlib's API.barneygale commentedon Jun 26, 2023
Closing this issue -
PurePathis already path-like and trying to do funky things in subclasses is probably more surprising than PurePath having__fspath__(). The latter may not be surprising at all depending on how you viewPurePath! Alex has pointed me towards a good solution forpathlib.AbstractPath.