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
pathlib.Path wants an rmtree method #77679
Comments
pathlib.Path wants the rmtree method from shutil I think we need this method for a couple of reasons.
Perhaps we need this as a method in the abstract base class that recursively uses the methods provided by the concrete implementations. I can look at the rmtree method for a reference implementation. Perhaps we should just give Path.rmdir a default recursive argument? Default would be False, of course, to retain current behavior. |
What is wrong with just using shutil.rmtree()? You can't deal with files with only using pathlib. You can't read ZIP archives, open temporary files, import modules, download files from Internet and open them in the webbrowser, run subprocesses, send files by e-mail, determine the MIME type of files, read WAV files with only using pathlib. |
I wasn't suggesting those things. After some thought, I would probably not support those things to be in pathlib either. Maybe they are "file" methods, but to me, they are not semantically "path" methods. That functionality is in much more specialized domain-oriented modules, and easy to discover. We need a recursive rmdir so that users aren't tempted to roll their own - and wind up deleting symlinked things. I *would* support some of those other shutil functions to become Path methods, perhaps move, copy2, and copytree, as they *are* path methods (you just need to supply another destination path), but I'm not finding it to be a pain point yet. |
I definitely would like this too. I have a code base that's only grazing on path usage, and I could completely convert it to pathlib, but one shutil.rmtree still remains... |
I am against this. shutil provides higher level API than pathlib, and pathlib should not depend on shutil. pathlib.Path represents a path, and its methods usually does involve filesystem operations, or involve just a single filesystem operation. shutil.rmtree() is a complex operation that needs to perform several simple operations, and it should be together with other complex operations in the shutil module. |
Indeed there is no reason to put all useful path informations under the Path class. Writing method calls instead of function calls is not an ideal. |
I'm disappointed to see this closed. For new (and old) users, it makes complete sense to have an rmtree method on the Path object itself. If I'm using pathlib, I try not to delegate to os.<things> for file operations, since it also tends to seem more OO and clean to stick with the object methods. Same thought process for shutil for rmtree. We already have things like owner() and group() that explicitly go import grp, pwd to do their job on Path objects. Why is shutil special with regards to using another piece of the standard library from pathlib? To me this request falls in the same boat as those functions; they were likely added for convenience and since it made sense. I believe the very same holds true for the request to add rmtree(). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: