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
8 of 15 tasks
barneygale opened this issue Jan 5, 2025 · 0 comments
Open
8 of 15 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
Merged
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
barneygale added a commit that referenced this issue Feb 16, 2025
@barneygale
GH-128520: Subclass abc.ABC in pathlib._abc (#128745)
a7d41a8 
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.

No change of behaviour in the public (non-abstract) classes.
barneygale added a commit to barneygale/cpython that referenced this issue Feb 16, 2025
@barneygale
pythonGH-128520: More consistent type-checking behaviour in pathlib
81a26f7 
In the following methods, skip casting of the argument to a path object if
the argument has a `with_segments` attribute. In `PurePath`:
`relative_to()`, `is_relative_to()`, `match()`, and `full_match()`. In
`Path`: `rename()`, `replace()`, `copy()`, `copy_into()`, `move()`, and
`move_into()`.

Previously the check varied a bit from method to method. The `PurePath`
methods used `isinstance(arg, PurePath)`; the `rename()` and `replace()`
methods always cast, and the remaining `Path` methods checked for a private
`_copy_writer` attribute.

We apply identical changes to relevant methods of the private ABCs. This
improves performance a bit, because `isinstance()` checks on ABCs are
expensive.
@bedevere-app bedevere-app bot mentioned this issue Feb 16, 2025
Merged
barneygale added a commit to barneygale/cpython that referenced this issue Feb 17, 2025
@barneygale
Merge branch 'main' into pythongh-128520-isinstance
7194a7e
barneygale added a commit that referenced this issue Feb 21, 2025
@barneygale
GH-128520: More consistent type-checking behaviour in pathlib (#130199)
d88677a 
In the following methods, skip casting of the argument to a path object if
the argument has a `with_segments` attribute. In `PurePath`:
`relative_to()`, `is_relative_to()`, `match()`, and `full_match()`. In
`Path`: `rename()`, `replace()`, `copy()`, `copy_into()`, `move()`, and
`move_into()`.

Previously the check varied a bit from method to method. The `PurePath`
methods used `isinstance(arg, PurePath)`; the `rename()` and `replace()`
methods always cast, and the remaining `Path` methods checked for a private
`_copy_writer` attribute.

We apply identical changes to relevant methods of the private ABCs. This
improves performance a bit, because `isinstance()` checks on ABCs are
expensive.
barneygale added a commit to barneygale/cpython that referenced this issue Mar 1, 2025
@barneygale
pythonGH-128520: Merge pathlib._abc into pathlib.types
a01ed0f 
There used to be a meaningful distinction between these modules: `pathlib`
imported `pathlib._abc` but not `pathlib.types`. This is no longer the
case (neither module is imported), so we move the ABCs as follows:

- `pathlib._abc.JoinablePath` --> `pathlib.types._JoinablePath`
- `pathlib._abc.ReadablePath` --> `pathlib.types._ReadablePath`
- `pathlib._abc.WritablePath` --> `pathlib.types._WritablePath`
@bedevere-app bedevere-app bot mentioned this issue Mar 1, 2025
Merged
barneygale added a commit to barneygale/cpython that referenced this issue Mar 1, 2025
@barneygale
pythonGH-128520: Merge pathlib._local into pathlib
3e0ba6c 
The `pathlib` module used to import stuff from both `_abc` and `_local`,
but nowadays the `_local` module provides the entire public pathlib
implementation, so there's no reason for the indirection.
@bedevere-app bedevere-app bot mentioned this issue Mar 1, 2025
Merged
barneygale added a commit that referenced this issue Mar 3, 2025
@barneygale
GH-128520: Merge pathlib._abc into pathlib.types (#130747)
d0eb01c 
There used to be a meaningful distinction between these modules: `pathlib`
imported `pathlib._abc` but not `pathlib.types`. This is no longer the
case (neither module is imported), so we move the ABCs as follows:

- `pathlib._abc.JoinablePath` --> `pathlib.types._JoinablePath`
- `pathlib._abc.ReadablePath` --> `pathlib.types._ReadablePath`
- `pathlib._abc.WritablePath` --> `pathlib.types._WritablePath`
barneygale added a commit to barneygale/cpython that referenced this issue Mar 3, 2025
@barneygale
Merge branch 'main' into pythongh-128520-local-module-move
6f08092
barneygale added a commit to barneygale/cpython that referenced this issue Mar 7, 2025
@barneygale
pythonGH-128520: pathlib ABCs: fix with_name() handling of empty names
1130cc5 
Raise `ValueError` from `pathlib.types._JoinablePath.with_name()` when
given an empty name, or acting upon a path with an empty name. This
behaviour matches `pathlib.PurePath.with_name()`.
@bedevere-app bedevere-app bot mentioned this issue Mar 7, 2025
Closed
barneygale added a commit that referenced this issue Mar 7, 2025
@barneygale
GH-128520: Merge pathlib._local into pathlib (#130748)
4bf25a0 
The `pathlib` module used to import stuff from both `_abc` and `_local`,
but nowadays the `_local` module provides the entire public pathlib
implementation, so there's no reason for the indirection.
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