Last but not least, I tend more towards the "rmtree" method just to make it crystal clear to everyone. Maybe docs could cross-refer both methods. Tree manipulations are inherently complicated and a lot can go wrong. Symmetry is not 100% given as you might delete more than what you've created (which was a single node path).
We already have tree removal functionality that this can use internally.
I am not much concerned about the internals; shutil.rmtree should work fine here. I am more concerned with the external interface (see also root/base/stem) and its impression on developers.
As for the name, one thing to consider is that making a recursive tree uses an argument.
And I think the argument would need to be keyword-only to avoid accidentally invoking it.
Why not adding a new method? I am still not convinced from a safety perspective that adding a new meaning-changing argument to a removal function is such a good idea. Just consider the following example. When deleting /my/soon/to/be/deleted/dir, you DO NOT delete a simple directory as the method name "rmdir" would suggest: - /my/soon/to/be/deleted/dir instead you delete something like this: - /my/soon/to/be/deleted/dir/d1/f1 - /my/soon/to/be/deleted/dir/d1/d3/f1 - /my/soon/to/be/deleted/dir/d1/d3/f2 - /my/soon/to/be/deleted/dir/d1/d3 - /my/soon/to/be/deleted/dir/d1/f2 - /my/soon/to/be/deleted/dir/d1/f3 - /my/soon/to/be/deleted/dir/d1 - /my/soon/to/be/deleted/dir/d2/f1 - /my/soon/to/be/deleted/dir/d2/f2 - /my/soon/to/be/deleted/dir/d2 - /my/soon/to/be/deleted/dir That is a completely different beast (a complete tree) and there is no way back once deleted. And there are a couple of other reasons when I look as the interface of shutil.rmtree and what "recursively" really means for pathlib. Best Sven