# Make pathlib extensible

**URL:** <https://discuss.python.org/t/make-pathlib-extensible/3428>\
**Category:** Ideas\
**Created:** [February 24, 2020, 12:15am UTC](https://discuss.python.org/t/make-pathlib-extensible/3428 "2020-02-24T00:15:07Z")\
**Posts on this page:** 20\
**Page:** 7

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [June 23, 2023, 5:52pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/121 "2023-06-23T17:52:00Z")

</div>

I’ve just discovered secret option 3: copy-paste ` __fspath__ ()` where it’s needed, no extra class required.

> <https://github.com/python/cpython/pull/106043>
>
> We made it possible to subclass \`pathlib.PurePath\` in a68e585, which landed in 3….12. However, user subclasses automatically inherit an \`\_\_fspath\_\_()\` method, which may not be appropriate. For example, a user subclass may implement a "virtual" filesystem to provide access to a \`.zip\` file or FTP server. But it would be highly surprising if \`open(FTPPath(...))\` attempted to open a \*local\* file.
> 
> This patch makes the \`os.PathLike\` interface opt-in. In pathlib itself, we opt into the \`os.PathLike\` interface for \`PurePosixPath\`, \`PureWindowsPath\` and \`Path\`. As \`PurePath\` is not instantiable (you always get a \`PurePosixPath\` or \`PureWindowsPath\` object back), this is backwards compatible with 3.11.
> 
> 
> \* Issue: gh-106037

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [June 26, 2023, 5:14pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/122 "2023-06-26T17:14:37Z")

</div>

Alex Waygood pointed me towards winning option 0: set ` __fspath__ = None` in `AbstractPath`, and then set it back to ` __fspath__ = PurePath. __fspath__ ` in `Path`. I considered this option originally and discounted it because it felt like a hack, and because the exception message was misleading. Well, it turned out every other option was an even uglier hack, and that Alex was prepared to [fix the exception message](https://github.com/python/cpython/commit/93a970ffbce58657cc99305be69e460a11371730). So now I’m aiming for this:

 ![image](https://us1.discourse-cdn.com/flex002/uploads/python1/original/2X/d/d1f964edab1d5f0a8df7824cac56ce19dbe38645.png)

Isn’t it beautiful? 😍 Thanks Alex!

The `tarfile.TarPath` implementation is working nicely. I’ll put a PR up as soon as I’ve landed a handful of pathlib test improvements (GH-106060 through 64 if anyone’s up for reviewing 🙏)

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 3, 2023, 8:49pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/123 "2023-07-03T20:49:50Z")

</div>

![](https://us1.discourse-cdn.com/flex002/uploads/python1/original/2X/4/41d7966feb88273f53dd90e32de5978dd6b6cc05.gif)

> <https://github.com/python/cpython/pull/106337>
>
> Add \`tarfile.TarPath\` class, which provides access to tar archive members via th…e \`pathlib.Path\` interface.
> 
> \## Implementation notes
> 
> In \`pathlib.py\`:
> 
> \- Split \`Path\` into \`\_VirtualPath\` and \`Path\`
> \- Implement \`\_VirtualPath.is\_junction()\` and \`is\_mount()\` using \`stat()\`. In the latter case, restore the implementation deleted in #31458
> \- Implement \`\_VirtualPath.resolve()\` using \`absolute()\` and \`readlink()\`
> \- Implement \`\_VirtualPath.\_scandir()\` using \`iterdir()\`
> 
> In \`test\_pathlib.py\`:
> 
> \- Add \`VirtualPathTest\` to exercise the \`\_VirtualPath\` class directly
> \- Split \`PathTest\` into \`DummyVirtualPathTest\` and \`PathTest\`. The former exercises a representative subclass of \`\_VirtualPath\`.
> \- Add \`DummyVirtualPathWithSymlinksTest\` to exercise a similar subclass, this time with symlink support.
> 
> In \`tarfile.py\`:
> 
> \- Add \`TarPath\`, which inherits from \`pathlib.\_VirtualPath\` and matches the interface of \`pathlib.Path\`
> \- Add \`\_TarStatResult\`, which is returned by \`TarPath.stat()\` and matches the interface of \`os.stat\_result\`
> \- Add \`\_TarPathWriter\`, which is returned by \`TarPath.open(mode="w")\`
> 
> In \`test\_tarfile.py\`:
> 
> \- Add \`TarPathTest\`, which is adapted from \`VirtualPathTest\` and uses a new \`testtarpath.tar\` archive
> \- Add \`TarPathFileTypeTest\`, which checks support for file types in the existing \`testtar.tar\` archive
> 
> \## Future work
> 
> \- Optimize \`tarfile.TarPath\`. The implementation in this PR is slow and would benefit from a lookup table for files, directories and symlinks.
> \- Make \`pathlib.\_VirtualPath\` public. There's still at least a couple of things to do first:
> - Make \`PurePath.\_flavour\` public
> - Figure out what to do with \`\_VirtualPath.\_\_hash\_\_()\`, \`\_\_eq\_\_()\`, and other comparison methods.
> 
> \---
> 
> 
> \* Issue: gh-89812

In addition to a public `tarfile.TarPath` class, the above PR adds a private `pathlib._VirtualPath` class (!!)

(I recently realised that “VirtualPath” is a ~~way cooler~~ more accurate name than “AbstractPath”, given its lack of true abstract methods. It should also put users in mind of [virtual file systems](https://en.wikipedia.org/wiki/Virtual_file_system), which is exactly what we want, I think.)

That PR is the largest I’ve ever logged, and it might take several months to land. But once it’s in, there’s not much more work left to make `pathlib.VirtualPath` public. Someone pinch me 😅

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 8, 2023, 3:56pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/124 "2023-07-08T15:56:42Z")

</div>

Q: Should the path flavour (either `ntpath` or `posixpath`) be a _class_ or _instance_ attribute?

```python
# Option 1
class MyPath(pathlib.VirtualPath):
    flavour = posixpath

# Option 2
class MyPath(pathlib.VirtualPath):
    def __init__ (self, *pathsegments):
        super(). __init__ (*pathsegments, flavour=posixpath)

    def with_segments(self, *pathsegments):
        # override to prevent passing *flavour* to initialiser.
        return type(self)(*pathsegments)

```

Option 2 allows a subclass to determine the flavour in ` __init__ ()` and pass it to `super()`, whereas in option 1 the flavour is fixed on the class. Once we choose an option, it ~~will~~ (edit: might) be hard to change our minds later.

Does anyone see any merit in allowing the flavour to be determined in ` __init__ ()`? So far I haven’t come up with any specific use case, but I’m not confident enough to rule it out either. Thank you!

Note that the flavour only determines the syntax/structure of the path. It’s not used for filesystem access.

---

<div class="post-metadata">

**Author:** ![Melendowski](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/melendowski/32/2960_2.png) [@Melendowski](https://discuss.python.org/u/Melendowski)\
**Post date:** [July 9, 2023, 3:55pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/125 "2023-07-09T15:55:42Z")

</div>

I think they should be class attribute

Barney, a while back is suggested the flavor should be a class parametrization through ` __init_subclass__ `. I still think this is a valid option.

> [@Fixing Subclassing in Pathlib](https://discuss.python.org/t/fixing-subclassing-in-pathlib/8983/4):
>
> If you’re going to provide a class decorator, why not just go the route of paramterizing your classes with a required keyword arg from \_\_init\_subclass\_\_? Require \_\_init\_subclass\_\_ to specify if posix or windows

Then you can guarantee it’s set and the subclass doesn’t have to go overriding anything

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 9, 2023, 4:15pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/126 "2023-07-09T16:15:07Z")

</div>

I’m not sure I follow! The `flavour` attribute is [set to `os.path` in `PurePath`](https://github.com/python/cpython/blob/ee46cb6aa959d891b0a480fea29f1eb991e0fad8/Lib/pathlib.py#L296), which will be the superclass of `VirtualPath`. And so subclasses of `VirtualPath` (including `Path`) will use the current OS’s flavour by default. Users should only need to override the flavour if their subclass _always_ uses POSIX or Windows path semantics.

---

<div class="post-metadata">

**Author:** ![Melendowski](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/melendowski/32/2960_2.png) [@Melendowski](https://discuss.python.org/u/Melendowski)\
**Post date:** [July 9, 2023, 4:17pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/127 "2023-07-09T16:17:51Z")

</div>

I’m severely misunderstanding then, my fault 😅

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 9, 2023, 4:49pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/128 "2023-07-09T16:49:01Z")

</div>

No worries! Thanks for your feedback on the class vs instance attribute bit. Éric has also [written](https://github.com/python/cpython/pull/106533#pullrequestreview-1520654303) in favour of a class attribute on GitHub.

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 9, 2023, 6:15pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/129 "2023-07-09T18:15:45Z")

</div>

At the risk of opening a pandora’s box:

Making _flavour_ (or _pathmod_ or whatever) a `PurePath` initialiser argument would allow us to remove the `PurePosixPath`, `PureWindowsPath`, `PosixPath` and `WindowsPath` classes in future, if that’s something we wanted to do. Many folks have observed over the years that pathlib’s class hierarchy is perhaps needlessly complex. The official docs put an inheritance diagram front-and-center and explain that, when you call `PurePath()` or `Path()`, you don’t get an object of type `PurePath` or `Path` back. It’s difficult to justify using subclasses to set path flavour when a simpler approach (initialiser argument) would work.

If we drive the flavour via an initialiser argument instead, it might look like this:

```python
# pure path using current OS path semantics
path = PurePath('foo')
assert type(path) is PurePath
assert path.pathmod is os.path

# pure path using POSIX semantics
path = PurePath('foo', pathmod=posixpath)
assert type(path) is PurePath
assert path.pathmod is posixpath

# pure path using Windows semantics 
path = PurePath('foo', pathmod=ntpath)
assert type(path) is PurePath
assert path.pathmod is ntpath

# concrete path does not accept pathmod argument
path = Path('foo')
assert type(path) is Path
assert path.pathmod is os.path

```

All ` __new__ ()` shenanigans are rendered unnecessary. Personally I find this a more appealing design than what we have now, and would gel perfectly with the proposed `VirtualPath`. But deprecating and removing 2/3rds of the `pathlib` public interface is about as churny as things come, so there would need to be strong support for this course of action. That doesn’t seem likely to me, but I figured I’d mention it just in case.

---

<div class="post-metadata">

**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\
**Post date:** [July 10, 2023, 9:04am UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/130 "2023-07-10T09:04:43Z")

</div>

> [@barneygale](#):
>
> Making _flavour_ (or _pathmod_ or whatever) a `PurePath` initialiser argument would allow us to remove the `PurePosixPath`, `PureWindowsPath`, `PosixPath` and `WindowsPath` classes in future, if that’s something we wanted to do.

I wouldn’t like that.  
I found `PurePosixPath` pretty useful for generic path-like operations – URL fragments, archive contents, even nested dict access. The minimal spec (only `/` and `\0` are special, leading `/` or `//` are more special) works great even outside Posix.  
Spelling `PurePosixPath` as `PurePath('foo', pathmod=posixpath)` sounds like unnecessary delving into implementation details.

---

<div class="post-metadata">

**Author:** ![h-vetinari](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/h-vetinari/32/1220_2.png) [@h-vetinari](https://discuss.python.org/u/h-vetinari)\
**Post date:** [July 10, 2023, 9:41am UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/131 "2023-07-10T09:41:16Z")

</div>

> [@encukou](#):
>
> Spelling `PurePosixPath` as `PurePath('foo', pathmod=posixpath)` sounds like unnecessary delving into implementation details.

Questions about churn aside, this is IMO equivalent in terms of “delving into implementation details”. It’s just more front-and-center in the name `PurePosixPath`. But as a beginner user, I’d certainly prefer not to have to think how my paths relate to posix (what’s that?), and minimize that exposure to a dim awareness (resp. short-and-sweet documentation) that there are different “path styles” between posix & windows.

Pulling on that thread a bit more, I don’t find `pathmod=` to be a good name for that kwarg, but `PurePath('foo', style=posix|windows)` looks like an appealing API to me.

Of course, the churn would be substantial, but if we are now able to envision / implement a way better long-term API, I don’t think we should forego such improvements indefinitely (as long as we can provide users with an easy way to migrate).

---

<div class="post-metadata">

**Author:** ![merwok](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/merwok/32/29_2.png) [@merwok](https://discuss.python.org/u/merwok)\
**Post date:** [July 10, 2023, 10:34am UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/132 "2023-07-10T10:34:23Z")

</div>

I am unsure about the name VirtualPath.

In other contexts I have seen, vfs or virtual file systems are all about letting you type paths that look like regular filesystem paths, and some software does custom things to return metadata or file contents.  
In the pathlib ecosystem, a TarPath class, or SshPath, or S3Path would be examples of virtual filesystems.  
But their base class itself is not implementing virtual path.

Barney suggested `PathBase` when I commented this on the PR, which feels great and easy to understand to me!

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 16, 2023, 2:27pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/133 "2023-07-16T14:27:34Z")

</div>

Thank you for your feedback @encukou and @h-vetinari! The idea of adding a _flavour_ argument to `PurePath` has been floating around in my head for years now, and I’m glad to finally be able to rule it out!

@merwok thanks, I’ve gone with `PathBase` in [the PR](https://github.com/python/cpython/pull/106337)! I think the docs (when we write them) could still mention virtual paths, right? e.g. “PathBase can be used to implement _virtual path objects_…”

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 16, 2023, 3:34pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/134 "2023-07-16T15:34:12Z")

</div>

✨ July 2023 progress report ✨

Thank you to all those who have been providing feedback on naming, hierarchies, etc. It’s so useful to bounce ideas off such talented and experienced devs!

As I mentioned in a previous post, I’ve put up a PR that adds a private `_PathBase` class:

> <https://github.com/python/cpython/pull/106337>
>
> Add private \`pathlib.\_PathBase\` class. This will be used by an experimental PyPI… package to incubate a \`tarfile.TarPath\` class.
> 
> \## Implementation notes
> 
> In \`pathlib.py\`:
> 
> \- Split \`Path\` into \`\_PathBase\` and \`Path\`
> \- Implement \`\_PathBase.is\_junction()\` and \`is\_mount()\` using \`stat()\`. In the latter case, restore the implementation deleted in #31458
> \- Implement \`\_PathBase.resolve()\` using \`absolute()\` and \`readlink()\`
> \- Implement \`\_PathBase.\_scandir()\` using \`iterdir()\`
> 
> In \`test\_pathlib.py\`:
> 
> \- Add \`PathBaseTest\` to exercise the \`\_PathBase\` class directly
> \- Split \`PathTest\` into \`DummyPathTest\` and \`PathTest\`. The former exercises a representative subclass of \`\_PathBase\`.
> \- Add \`DummyPathWithSymlinksTest\` to exercise a similar subclass, this time with symlink support.
> 
> \## Questionable bits
> 
> In \`pathlib.py\`, the \`\_PathBase.is\_junction()\` and \`\_PathBase.resolve()\` methods are new code. The latter is very performance-sensitive and may need more work.
> 
> \## Future work
> 
> \- Make \`pathlib.\_PathBase\` public. There's still at least a couple of things to do first:
> - Make \`PurePath.\_flavour\` public
> - Figure out what to do with \`\_PathBase.\_\_hash\_\_()\`, \`\_\_eq\_\_()\`, and other comparison methods.
> 
> \---
> 
> 
> \* Issue: gh-89812

That PR has been slimmed down: it originally added `tarfile.TarPath` too, but the expected behaviour of paths involving symlinks wasn’t clear, and so I’m going to work on `TarPath` in a PyPI package first.

When that PR lands, the remaining work is:

- Add a public `PurePath.pathmod` class attribute (PR: [GH-106533](https://github.com/python/cpython/pull/106533))
- Figure out what to do with `_PathBase. __hash__ ()`, ` __eq__ ()`, ` __lt__ ()`, etc (any opinions?)
- Make `pathlib.PathBase` public!

For the first time, I feel confident that this project _will_ succeed. There are no architectural problems remaining in pathlib that would prevent it, nor any major decisions to be made (touch wood). It will be immediately useful upon release, and I think it could grow into one of Python’s best-loved features as third-party APIs begin to accept `os.PathLike | pathlib.PathBase` for _path_ arguments. Eventually users should be able to do things like:

```python
shutil.copytree(FTPPath(...), TarPath(...))
pandas.read_csv(S3Path(...))
image.save(TarPath(...)) # PIL

```

We’re doing for _path objects_ what PEP 3116 and the `io` module did for _file objects_ 🙂

That’s it for now. Thanks again to everyone who has helped with this!

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 16, 2023, 4:14pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/135 "2023-07-16T16:14:36Z")

</div>

For my fellow visual learners, here’s a venn diagram showing `os.PathLike` and `pathlib.PathBase`:

 ![image](https://us1.discourse-cdn.com/flex002/uploads/python1/original/2X/d/d5230ebdb73abecd11ae8ad1e8d075a154d5856f.png)

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 26, 2023, 10:35pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/136 "2023-07-26T22:35:21Z")

</div>

The patch in review includes a `PathBase.as_uri()` method that raises `UnsupportedOperation`. I expect that some subclasses of `PathBase` will override that method, e.g. to return `s3://` or `ftp://` URIs.

Q: Should we add a symmetrical `PathBase.from_uri()` classmethod? This would provide an explicit means to contruct a path object (and its backend) from a URI - for example, an `FTPPath.from_uri()` method could parse the host/port/user/passwd from the URI, construct an `ftplib.FTP` object, and then wrap it in an `FTPPath` object.

For `Path.from_uri()` (local paths), I have a local branch that handles [RFC 8089](https://datatracker.ietf.org/doc/html/rfc8089) `file:` URIs, including the weird ones with 4 or 5 leading slashes, such as those produced by [`urllib.request.pathname2url()`](https://docs.python.org/3/library/urllib.request.html#urllib.request.pathname2url).

---

<div class="post-metadata">

**Author:** ![Conchylicultor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/conchylicultor/32/4052_2.png) [@Conchylicultor](https://discuss.python.org/u/Conchylicultor)\
**Post date:** [July 27, 2023, 7:54am UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/137 "2023-07-27T07:54:28Z")

</div>

I don’t think there should be a `PathBase.from_uri()`. Instead I feel the subclasses should support uri directly in there ` __init__ ` function. This is already the case for some pathlib implementations:

```auto
from etils import epath
import upath

epath.Path('gs://xxx/yyy')
upath.UPath('s3://test_bucket')

```

An additional method would add redundancy/confusion and feel less natural I think. But that’s just my opinion.

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 27, 2023, 3:58pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/138 "2023-07-27T15:58:47Z")

</div>

Thanks! Assuming `upath.UPath('s3:...')` delegates to an `S3Path` class, how should users call _its_ initialiser? So far I’ve been gunning for something like this:

```auto
client = boto3.client('s3')
path = S3Path('downloads', 'foo.tar.gz', client=client, bucket='foo')

```

The positional arguments are specified just like in `PurePath` and `Path` - a list of path segments to join. The keyword arguments _add_ to the existing interface, rather than replacing it.

I’m not sure how to add URIs into this mix. In some cases you can distinguish URIs from file paths, but not always\* and so positional arguments don’t seem right. A _uri_ keyword argument might work, but it makes other arguments redundant and complicates the interface IMO. This is why I still lean towards a `from_uri()` classmethod, as the URI may be used to fill several initialiser parameters. What do you think?

(\*) for example, `file:/etc/hosts` is both a valid file URI _and_ a valid relative POSIX path

---

<div class="post-metadata">

**Author:** ![jamestwebber](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamestwebber/32/12799_2.png) [@jamestwebber](https://discuss.python.org/u/jamestwebber)\
**Post date:** [July 27, 2023, 4:05pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/139 "2023-07-27T16:05:28Z")

</div>

> [@barneygale](#):
>
> The positional arguments are specified just like in `PurePath` and `Path` - a list of path segments to join. The keyword arguments _add_ to the existing interface, rather than replacing it.

To be honest I didn’t know that was a thing, I almost always construct a `Path` with a single argument, and add on with `/` if needed.

I think it would be nice if the `client` wasn’t needed for s3 or gcs paths to work, since you don’t necessarily want to _interact_ with your cloud storage when you’re working with paths. _e.g._ if you’re just formatting some metadata for documentation, or something.

---

<div class="post-metadata">

**Author:** ![barneygale](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barneygale/32/1882_2.png) [@barneygale](https://discuss.python.org/u/barneygale)\
**Post date:** [July 27, 2023, 4:08pm UTC](https://discuss.python.org/t/make-pathlib-extensible/3428/140 "2023-07-27T16:08:28Z")

</div>

> [@jamestwebber](#):
>
> I think it would be nice if the `client` wasn’t needed for s3 or gcs paths to work, since you don’t necessarily want to _interact_ with your cloud storage when you’re working with paths. _e.g._ if you’re just formatting some metadata for documentation, or something.

Would `PurePosixPath` work? It’s designed not to perform any (virtual) filesystem access.

[Previous page](https://discuss.python.org/t/make-pathlib-extensible/3428.md?page=6)

[Next page](https://discuss.python.org/t/make-pathlib-extensible/3428.md?page=8)