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.

Sign up for GitHub

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

Jump to bottom

Make pathlib ABCs usable by zipfile.Path #128520

Open
3 of 13 tasks
barneygale opened this issue Jan 5, 2025 · 0 comments
Open
3 of 13 tasks

Make pathlib ABCs usable by zipfile.Path #128520

barneygale opened this issue Jan 5, 2025 · 0 comments
Labels
stdlib Python modules in the Lib dir topic-pathlib type-feature A feature request or enhancement

Comments

@barneygale
Copy link
Contributor

barneygale commented Jan 5, 2025 •
edited
Loading

Feature or enhancement

This issue covers the final tasks needed to make the pathlib ABCs worthy of using in zipfile.Path (i.e. zipp.Path).

Tasks

Discussion: https://discuss.python.org/t/make-pathlib-extensible/3428

Linked PRs
@barneygale barneygale added type-feature A feature request or enhancement topic-pathlib and removed type-feature A feature request or enhancement labels Jan 5, 2025
barneygale added a commit to barneygale/cpython that referenced this issue Jan 5, 2025
@barneygale
pythonGH-128520: Divide pathlib ABCs into three classes
c3bb4ff 
In the private pathlib ABCs, rename `PurePathBase` to `JoinablePath`, and
split `PathBase` into `ReadablePath` and `WritablePath`. This improves the
API fit for read-only virtual filesystems.

The split of `PathBase` entails a similar split of `CopyWorker` (implements
copying) and the test cases in `test_pathlib_abc`. For a couple of reasons,
this isn't quite possible yet.

In a later patch, we'll make `WritablePath` inherit directly from
`JoinablePath` rather than `ReadablePath`.
barneygale added a commit to barneygale/cpython that referenced this issue Jan 5, 2025
@barneygale
pythonGH-128520: Divide pathlib ABCs into three classes
53d3db7 
In the private pathlib ABCs, rename `PurePathBase` to `JoinablePath`, and
split `PathBase` into `ReadablePath` and `WritablePath`. This improves the
API fit for read-only virtual filesystems.

The split of `PathBase` entails a similar split of `CopyWorker` (implements
copying) and the test cases in `test_pathlib_abc`. For a couple of reasons,
this isn't quite possible yet.

In a later patch, we'll make `WritablePath` inherit directly from
`JoinablePath` rather than `ReadablePath`.
@bedevere-app bedevere-app bot mentioned this issue Jan 5, 2025
Merged
@barneygale barneygale changed the title Prepare pathlib ABCs for PEP Make pathlib ABCs usable by zipfile.Path Jan 5, 2025
@picnixz picnixz added stdlib Python modules in the Lib dir type-feature A feature request or enhancement and removed type-feature A feature request or enhancement labels Jan 6, 2025
barneygale added a commit that referenced this issue Jan 11, 2025
@barneygale
GH-128520: Divide pathlib ABCs into three classes (#128523)
22a4421 
In the private pathlib ABCs, rename `PurePathBase` to `JoinablePath`, and
split `PathBase` into `ReadablePath` and `WritablePath`. This improves the
API fit for read-only virtual filesystems.

The split of `PathBase` entails a similar split of `CopyWorker` (implements
copying) and the test cases in `test_pathlib_abc`.

In a later patch, we'll make `WritablePath` inherit directly from
`JoinablePath` rather than `ReadablePath`. For a couple of reasons,
this isn't quite possible yet.
barneygale added a commit to barneygale/cpython that referenced this issue Jan 11, 2025
@barneygale
pythonGH-128520: Subclass abc.ABC in pathlib._abc
95688bb 
Convert `JoinablePath`, `ReadablePath` and `WritablePath` to real ABCs
derived from `abc.ABC`.

Make `JoinablePath.parser` abstract, rather than defaulting to `posixpath`.

Register `PurePath` and `Path` as virtual subclasses of the ABCs rather
than deriving. This avoids a hit to path object instantiation performance.
@bedevere-app bedevere-app bot mentioned this issue Jan 11, 2025
Open
barneygale added a commit to barneygale/cpython that referenced this issue Jan 19, 2025
@barneygale
pythonGH-128520: Make pathlib._abc.WritablePath a sibling of `Reada…
f31aeb8 
…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.
- `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`.

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()`.
barneygale added a commit to barneygale/cpython that referenced this issue Jan 19, 2025
@barneygale
pythonGH-128520: Make pathlib._abc.WritablePath a sibling of `Reada…
e13ed9c 
…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`.
@bedevere-app bedevere-app bot mentioned this issue Jan 19, 2025
Merged
barneygale added a commit to barneygale/cpython that referenced this issue Jan 19, 2025
@barneygale
Merge branch 'main' into pythongh-128520-fix-inheritance
4e3ec3a
barneygale added a commit that referenced this issue Jan 21, 2025
@barneygale
GH-128520: Make pathlib._abc.WritablePath a sibling of `ReadablePat…
01d9150 
…h` (#129014)

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 GH-125413 is resolved, we'll be able to move
  the `CopyReader` functionality into `ReadablePath.info` and eliminate
  `ReadablePath._copy_reader`.
barneygale added a commit to barneygale/cpython that referenced this issue Feb 8, 2025
@barneygale
pythonGH-128520: Read path metadata from pathlib.types.PathInfo whe…
1fb81f5 
…n copying

Add private `PathInfo._stat()` and `_xattrs()` methods, which are called
when copying metadata to a local path. This removes all need for the
`CopyReader` and `_LocalCopyReader` classes, so we delete them. The
`CopyWriter` and `_LocalCopyWriter` classes are moved into `pathlib._os`,
renamed to `Copier` and `LocalCopier`, and refactored so that only one
copier object is created per copy operation.

This internal refactor shouldn't have any user-facing impact.
@bedevere-app bedevere-app bot mentioned this issue Feb 8, 2025
Closed
@picnixz picnixz added the type-feature A feature request or enhancement label Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
stdlib Python modules in the Lib dir topic-pathlib type-feature A feature request or enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@barneygale @picnixz