Skip to content
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

GH-128520: Make pathlib._abc.WritablePath a sibling of ReadablePath #129014

Merged
merged 3 commits into from
Jan 21, 2025

Conversation

barneygale
Copy link
Contributor

@barneygale barneygale commented Jan 19, 2025

In the private pathlib ABCs, support write-only virtual filesystems by making WritablePath inherit directly from JoinablePath, rather than subclassing ReadablePath. There are two complications:

Problem 1: ReadablePath.open() applies to both reading and writing

Solution: a new pathlib._abc.magic_open() function replaces the open() method, which is dropped from the ABCs but remains in pathlib.Path. The function works like io.open(), but additionally accepts objects with __open_rb__() or __open_wb__() methods as appropriate for the mode. These new dunders are made abstract methods of ReadablePath and WritablePath respectively. If the pathlib ABCs are made public, we could consider blessing an "openable" protocol and supporting it in io.open(), removing the need for pathlib._abc.magic_open().

Problem 2: ReadablePath.copy is secretly an object that supports the read side of copying, whereas WritablePath.copy is a subclass additionally supporting the write side

Solution: ReadablePath.copy becomes a true method, whereas WritablePath.copy is deleted. A new ReadablePath._copy_reader property provides a CopyReader object, and similarly WritablePath._copy_writer is a CopyWriter object. Once GH-125413 is resolved, we'll be able to move the CopyReader functionality into ReadablePath.info and eliminate ReadablePath._copy_reader.

…blePath`

In the private pathlib ABCs, support write-only virtual filesystems by
making `WritablePath` inherit directly from `JoinablePath`, rather than
subclassing `ReadablePath`.

There are two complications:

- `ReadablePath.open()` applies to both reading and writing
- `ReadablePath.copy` is secretly an object that supports the *read* side
  of copying, whereas `WritablePath.copy` is a different kind of object
  supporting the *write* side

We untangle these as follow:

- A new `pathlib._abc.magic_open()` function replaces the `open()` method,
  which is dropped from the ABCs but remains in `pathlib.Path`. The
  function works like `io.open()`, but additionally accepts objects with
  `__open_rb__()` or `__open_wb__()` methods as appropriate for the mode.
  These new dunders are made abstract methods of `ReadablePath` and
  `WritablePath` respectively.  If the pathlib ABCs are made public, we
  could consider blessing an "openable" protocol and supporting it in
  `io.open()`, removing the need for `pathlib._abc.magic_open()`.
- `ReadablePath.copy` becomes a true method, whereas `WritablePath.copy` is
  deleted. A new `ReadablePath._copy_reader` property provides a
  `CopyReader` object, and similarly `WritablePath._copy_writer` is a
  `CopyWriter` object. Once pythonGH-125413 is resolved, we'll be able to move
  the `CopyReader` functionality into `ReadablePath.info` and eliminate
  `ReadablePath._copy_reader`.
@barneygale barneygale merged commit 01d9150 into python:main Jan 21, 2025
37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant