Thanks to visit codestin.com
Credit goes to github.com

Skip to content

GH-130608: Remove dirs_exist_ok argument from pathlib.Path.copy() #130610

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

Merged
merged 1 commit into from
Feb 28, 2025

Conversation

barneygale
Copy link
Contributor

@barneygale barneygale commented Feb 26, 2025

Per the issue:

(Background: pathlib.Path.copy() is new in Python 3.14, so it hasn't been released yet.)

I don't think there's a compelling case to support a dirs_exist_ok argument in the initial version of Path.copy(). Most Python users don't need "copy and merge directory" functionality. Particularly unlucky users might use the wrong source or target path, and perform a large directory tree merge that is difficult to unpick.

We could add this back in later, in response to user demand.


📚 Documentation preview 📚: https://cpython-previews--130610.org.readthedocs.build/

…opy()`

This feature isn't sufficiently motivated.
@barneygale
Copy link
Contributor Author

Hi Paul, I requested your review because you helped with a similar PR few months back: #123337

To explain my motivations a bit:

I'm trying to be extremely careful about adding pathlib features I might later regret. It's already happened more than once while I've been maintaining pathlib 🙃

In this case, the implementation uses WritablePath.mkdir(exist_ok=dirs_exist_ok), but I'd like to remove the exist_ok argument because it implies readability, whereas WritablePath is otherwise write-only. Maybe this is solvable some other way, but for now I'd quite like to play it safe.

Hope that makes sense, thank you.

@pfmoore
Copy link
Member

pfmoore commented Feb 28, 2025

Looks OK to me, and I agree with your reasoning. Until we know how people are going to use the new extensibility, it's better to keep the requirements minimal. We can add functionality later if it's needed, and 3rd party providers won't have a problem with it.

@barneygale
Copy link
Contributor Author

barneygale commented Feb 28, 2025

Excellent, thanks for your help :]

@barneygale barneygale merged commit b545450 into python:main Feb 28, 2025
48 checks passed
seehwan pushed a commit to seehwan/cpython that referenced this pull request Apr 16, 2025
…opy()` (python#130610)

This feature isn't sufficiently motivated.
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.

2 participants