There’s some interesting discussion on the tracker about whether it makes sense for pathlib to import shutil.copy2, and whether copy2() and friends are best placed in shutil or some other module.
I think it makes sense to continue the discussion here. My take:
The implementations of shutil.copy2(), copyfile(), and copystat() deal with some low-level OS and filesystem details (code), whereas pathlib normally delegates all that stuff to os and os.path. In these instances, shutil seems lower-level than anything in pathlib.
The implementations of shutil.copytree(), rmtree() and move() are mostly without any OS-specific details - they string together the lower-level copy() functions, and other functions from os, in just the right way. They seem to be on about the same conceptual level as pathlib’s features, like Path.glob() and Path.walk().
The archiving functions provided by shutil seem to be on a higher level still, as they provide a generic interface to multiple formats. I’d say they’re higher level than anything in pathlib.
What to make of all this? @steve.dowersuggested that the copy functions might be best placed in the os module. @storchakapushed back on this. I feel ambivalent - I agree with Steve that the copy functions feel more at home in os, but they don’t seem obviously out-of-place in shutil either, and I’d rather not move ~1000 lines of code unless I have plenty of buy-in! @thesamesamnoted an issue and PR about using copy_file_range() on Linux to speed up copying.
A shiny penny for anyone’s thoughts! Should the copy functions remain in shutil? If so, is it (un)reasonable to import and use them from pathlib?