Repository navigation
Support for detecting the flavour of pathlib subclasses #100502
Description
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 semanticsNote 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 thirdpartypathpackage)
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
PurePosixPathandPureWindowsPathshould 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.
Activity
pythonGH-100502: Add `pathlib.PurePath.flavour` attribute
pythonGH-100502: Add `pathlib.PurePath.flavour` attribute
pythonGH-100502: Add `pathlib.PurePath.flavour` attribute
merwok commentedon Jul 8, 2023
pathmodis 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.flavouris a bit more vague but okay;accessoris also available!merwok commentedon Jul 8, 2023
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'andos.path is posixpath.barneygale commentedon Jul 8, 2023
Thanks for the feedback!
pathmodsounds good to me. It occurs to me that the pathlib documentation already refers toPureWindowsPath,PurePosixPathetc as "flavours", and so re-using that term could be confusing.Agree also on
is_posix()GH-100502: Add `pathlib.PurePath.pathmod` attribute (GH-106533)
barneygale commentedon Jul 19, 2023
Implemented in c6c5665 / #106533
barneygale commentedon Dec 19, 2023
@merwok I'm beginning to have doubts about the solution I implemented. I think the new, internal
PurePathBaseclass ought to support syntax customization beyond a fat "NT or POSIX" switch, and that perhaps the path module should be an internal implementation detail ofPurePath, rather than an attribute ofPurePathBase. 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 commentedon Dec 19, 2023
Would you revert to
_flavouror keep the new name we came to and mark it private with_pathmod?barneygale commentedon Dec 19, 2023
I think I'd keep the new name and mark it as private with
_pathmodmerwok commentedon Dec 19, 2023
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!
Revert "pythonGH-100502: Add `pathlib.PurePath.pathmod` attribute (py…
barneygale commentedon Dec 19, 2023
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._abcmodule, and though I'm pretty satisfied with the I/O aspects of thePathBaseclass, I'm much less convinced that the pure aspects of thePurePathBaseclass are correct, and I expect I'll need to iterate on them over the coming months.Yes that's right.
Thanks for the advice - I'll follow your suggestion to not revert yet. I appreciate your take on this :)
barneygale commentedon Jan 12, 2024
I've played with two approaches:
pathmodfrom PurePathBase to PurePath, and making somePurePathBasemethods directly raiseUnsupportedOperationPurePathBase.pathmodand changing its value to a newPathModuleBaseABC.Both of these have the effect of making
PurePathBasemethods raiseUnsupportedOperation, but the first option is really nasty, as it meansPathBasehas 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: #113893Re-resolving this issue.