Support for detecting the flavour of pathlib subclasses #100502

barneygale · 2022-12-24T16:34:13Z

Feature or enhancement

Provide a way of checking whether a user subclass of pathlib.PurePath and Path uses POSIX or Windows semantics

The Problem

Now that #68320 is resolved, users can subclass pathlib.PurePath and Path directly:

import pathlib

class MyPath(pathlib.Path):
    pass

path = MyPath('foo')

However, there's no (public) procedure to detect whether an instance of MyPath uses POSIX or Windows semantics.

A non-public way of doing it:

path._flavour is posixpath  # Check whether the path object uses POSIX semantics
path._flavour is ntpath  # Check whether the path uses Windows semantics
path._flavour is os.path  # Check whether the path uses the current OS's semantics

Note that checking isinstance(path, PurePosixPath) (etc) won't work, as user subclasses of PurePath and Path do not have the POSIX- and Windows-specific subclasses in their class hierarchy.

The Proposal

Make the _flavour attribute public; document it. Possible names:

flavour (simply remove the underscore)
pathmod (used internally in older pathlib versions)
module (used in the longstanding thirdparty path package)

Alternatives

We could make the PurePosixPath and PureWindowsPath classes 'protocols', which support isinstance() checks even when the passed object isn't a conventional subclass. But:

The implementation will be more complex
It could open a can of worms about whether PurePosixPath and PureWindowsPath should be proper protocols, and not directly instantiable.

A further alternative would be to add an is_posix() method, which gels pretty nicely with the existing is_*() and as_posix() methods.

Linked PRs

GH-100502: Add pathlib.PurePath.pathmod attribute #106533

The text was updated successfully, but these errors were encountered:

This instance attribute stores the implementation of `os.path` used for low-level path operations: either `posixpath` or `ntpath`. The `PurePath` and `Path` initialisers gain a *flavour* keyword-only argument that sets the flavour. This argument is not available in the Posix- and Windows-specific subclasses, and as the `PurePath` and `Path` classes are not directly instantiable, it is available therefore only in user subclasses of `PurePath and `Path`. Such subclasses may determine their flavour in `__init__()` and supply the flavour to `super()`.

This instance attribute stores the implementation of `os.path` used for low-level path operations: either `posixpath` or `ntpath`. The `PurePath` and `Path` initialisers gain a *flavour* keyword-only argument. This argument is not available in the Posix- and Windows-specific subclasses, and as the `PurePath` and `Path` classes are not directly instantiable, it is available therefore only in user subclasses of `PurePath` and `Path`. Such subclasses may determine their flavour in `__init__()` and supply the flavour to `super()`.

merwok · 2023-07-08T06:05:47Z

pathmod is not a bad name! It makes it clear that the value is (normally) one of the path modules, and Python being Python it doesn’t prevent someone using another kind of object for custom needs.

flavour is a bit more vague but okay; accessor is also available!

merwok · 2023-07-08T06:07:22Z

About is_posix: I don’t think the name is clear enough. Without reading docs, it could be interpreted as a question about the current platform, or the path module, or a check for some posix spec conformity, or even a question about the form of the paths?!
But maybe my worry is unfounded and it would be fine, we have os.name == 'posix' and os.path is posixpath.

barneygale · 2023-07-08T15:47:15Z

Thanks for the feedback! pathmod sounds good to me. It occurs to me that the pathlib documentation already refers to PureWindowsPath, PurePosixPath etc as "flavours", and so re-using that term could be confusing.

Agree also on is_posix()

This instance attribute stores the implementation of `os.path` used for low-level path operations: either `posixpath` or `ntpath`.

barneygale · 2023-07-19T18:00:50Z

Implemented in c6c5665 / #106533

barneygale · 2023-12-19T20:45:01Z

@merwok I'm beginning to have doubts about the solution I implemented. I think the new, internal PurePathBase class ought to support syntax customization beyond a fat "NT or POSIX" switch, and that perhaps the path module should be an internal implementation detail of PurePath, rather than an attribute of PurePathBase. Would you mind if I revert #106533? It's only been available in 3.13 alphas so far, so it's safe to do so.

merwok · 2023-12-19T21:31:12Z

Would you revert to _flavour or keep the new name we came to and mark it private with _pathmod?

barneygale · 2023-12-19T21:32:32Z

I think I'd keep the new name and mark it as private with _pathmod

merwok · 2023-12-19T21:50:18Z

This is related to the ongoing discussions about preserving final slash and follow_symlinks (and co) as implicit parameters, yes?
You’re thinking that the addition of parameters to track choices for these properties removes or weakens the usefulness of checking that a Path class or subclass uses posix or nt base rules?

Generally I trust you to shepherd the changes needed to support important features.
In this case I would suggest that maybe it’s not required to revert right now, as the discussions haven’t reached their conclusions and it’s not clear how the pathlib design should change to move in a good direction.
The first beta is in May, so pathmod could be hidden, removed or changed between now and then 🙂

If you still think the attribute should hidden now, then go ahead!

…thonGH-106533)" This reverts commit c6c5665.

barneygale · 2023-12-19T22:10:14Z

This is related to the ongoing discussions about preserving final slash and follow_symlinks (and co) as implicit parameters, yes?

It's related to those discussions, but more directly to the work on pathlib ABCs which has been going on at the same time. There's now a private pathlib._abc module, and though I'm pretty satisfied with the I/O aspects of the PathBase class, I'm much less convinced that the pure aspects of the PurePathBase class are correct, and I expect I'll need to iterate on them over the coming months.

You’re thinking that the addition of parameters to track choices for these properties removes or weakens the usefulness of checking that a Path class or subclass uses posix or nt base rules?

Yes that's right.

Thanks for the advice - I'll follow your suggestion to not revert yet. I appreciate your take on this :)

barneygale · 2024-01-12T01:35:49Z

I've played with two approaches:

Moving pathmod from PurePathBase to PurePath, and making some PurePathBase methods directly raise UnsupportedOperation
Keeping PurePathBase.pathmod and changing its value to a new PathModuleBase ABC.

Both of these have the effect of making PurePathBase methods raise UnsupportedOperation, but the first option is really nasty, as it means PathBase has two sets abstract methods that are largely independent. The second option is uses composition rather than inheritance and works out much nicer. I've put it up as a PR: #113893

Re-resolving this issue.

barneygale added the type-feature A feature request or enhancement label Dec 24, 2022

AlexWaygood added the topic-pathlib label Dec 24, 2022

barneygale mentioned this issue Jun 7, 2023

Should UPath.__new__ return pathlib.Path instances for local paths fsspec/universal_pathlib#90

Closed

bedevere-bot mentioned this issue Jul 7, 2023

GH-100502: Add pathlib.PurePath.pathmod attribute #106533

Merged

barneygale added a commit that referenced this issue Jul 19, 2023

GH-100502: Add pathlib.PurePath.pathmod attribute (GH-106533)

c6c5665

This instance attribute stores the implementation of `os.path` used for low-level path operations: either `posixpath` or `ntpath`.

barneygale closed this as completed Jul 19, 2023

barneygale reopened this Dec 19, 2023

barneygale added a commit to barneygale/cpython that referenced this issue Dec 19, 2023

Revert "pythonGH-100502: Add pathlib.PurePath.pathmod attribute (py…

cfa2e96

…thonGH-106533)" This reverts commit c6c5665.

merwok mentioned this issue Jan 11, 2024

Drop Python 3.7 and add Python 3.12 justindujardin/pathy#112

Merged

barneygale closed this as completed Jan 12, 2024

barneygale mentioned this issue Jan 25, 2024

Rename pathlib.PurePath.pathmod #114575

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for detecting the flavour of pathlib subclasses #100502

Support for detecting the flavour of pathlib subclasses #100502

barneygale commented Dec 24, 2022 •

edited by bedevere-bot

merwok commented Jul 8, 2023

merwok commented Jul 8, 2023 •

edited

barneygale commented Jul 8, 2023

barneygale commented Jul 19, 2023

barneygale commented Dec 19, 2023 •

edited

merwok commented Dec 19, 2023

barneygale commented Dec 19, 2023 •

edited

merwok commented Dec 19, 2023

barneygale commented Dec 19, 2023 •

edited

barneygale commented Jan 12, 2024 •

edited

Support for detecting the flavour of pathlib subclasses #100502

Support for detecting the flavour of pathlib subclasses #100502

Comments

barneygale commented Dec 24, 2022 • edited by bedevere-bot

Feature or enhancement

The Problem

The Proposal

Alternatives

Linked PRs

merwok commented Jul 8, 2023

merwok commented Jul 8, 2023 • edited

barneygale commented Jul 8, 2023

barneygale commented Jul 19, 2023

barneygale commented Dec 19, 2023 • edited

merwok commented Dec 19, 2023

barneygale commented Dec 19, 2023 • edited

merwok commented Dec 19, 2023

barneygale commented Dec 19, 2023 • edited

barneygale commented Jan 12, 2024 • edited

barneygale commented Dec 24, 2022 •

edited by bedevere-bot

merwok commented Jul 8, 2023 •

edited

barneygale commented Dec 19, 2023 •

edited

barneygale commented Dec 19, 2023 •

edited

barneygale commented Dec 19, 2023 •

edited

barneygale commented Jan 12, 2024 •

edited