On Wed, 19 Oct 2022 at 09:17, Todd <toddrjen@gmail.com> wrote:
>
> On Tue, Oct 18, 2022 at 5:00 PM Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Wed, 19 Oct 2022 at 06:50, Todd <toddrjen@gmail.com> wrote:
>> >
>> > Currently, pathlib supports pretty much all common filesystem operations. You can create, move, and delete both files and directories. One big omission is copying. You need shutil for that.
>> >
>> > Whatever the original intent might have been behind pathlib, it is now effectively the standard tool for filesystem operations. As such, excluding copying alone from basic operations creates an unnecessary hurdle for users. It also increases the difficulty of doing such operations since there is no hint within the pathlib documentation on how to copy, new users basically need to google it to find out. That is fine for less common operations, but far from ideal from a basic one like copying.
>> >
>>
>> Ah. I would look at solving this the other way: since this really
>> isn't a path operation (in the same sense that moving/renaming and
>> deleting are), keep it in shutil, but improve discoverability with a
>> docs reference.
>>
>> ChrisA
>
>
> How is it any less of a "path operation" than moving files, reading and writing files, making directories, and deleting files?
At a file system level, those are nothing more than directory entry
manipulation. (Reading and writing might count as slightly more than
that, but practicality beats purity.) Copying a file involves a lot
more work, and is not a simple operation done in the directory entry,
so it's more of a separate tool.
Yes, and I would say practically copying a file is at least as much a valid part of pathlib as basic file/io. File i/o is a builtin for python, so putting it pathlib is even less useful than copying, which requires a separate import.
Also, not everyone agrees on what
"copying" means, so there'll be various platform-specific concepts.
But Python already has such a tool, we are simply exposing it in a more convenient way.
In theory, you could take literally every possible action that could
be done on a file and make it into a Path method. Do we need a method
to read a .WAV file and return its headers, or is that better left in
the 'wave' module? There's a reason that huge slabs of Python are
built on protocols rather than methods. Assuming that shutil.copyfile
accepts Path objects (and if it doesn't, that should definitely be
fixed), is it really a problem for the Path objects to not have a copy
method?
Operating on specific file types (other than text files) is not considered a core filesystem operation in any operating system I know. In contrast copying is, such as in UNIX 1, Multics, PC-DOS 1.0, and OS/2.
Again, whatever the original intent behind pathlib was, its effective use today is as the primary recommended way to deal with basic file operations. From what I can tell, copying is pretty much universally treated as a basic file operation in pretty much every major operating system.