On Sun, Nov 22, 2020 at 3:27 PM Abdulla Al Kathiri < alkathiri.abdulla@gmail.com> wrote:
On Nov 22, 2020, at 11:53 PM, Todd <toddrjen@gmail.com> wrote:
I know enhancements to pathlib gets brought up occasionally, but it doesn't look like anyone has been willing to take the initiative and see things through to completion. I am willing to keep the ball rolling here and even implement these myself. I have some suggestions and I would like to discuss them. I don't think any of them are significant enough to require a pep. These can be split it into independent threads if anyone prefers.
1. copy
The big one people keep bringing up that I strongly agree on is a "copy" method. This is really the only common file manipulation task that currently isn't possible. You can make files, read them, move them, delete them, create directories, even do less common operations like change owners or create symlinks or hard links.
A common objection is that pathlib doesn't work on multiple paths. But that isn't the case. There are a ton of methods that do that, including:
* symlink_to * link_to * rename * replace * glob * rglob * iterdir * is_relative_to * relative_to * samefile
I think this is really the only common file operation that someone would need to switch to a different module to do, and it seems pretty strange to me to be able to make symbolic or hard links to a file but not straight up copy one.
2. recursive remove
This could be a "recursive" option to "rmdir" or a "rmtree" method (I prefer the option). The main reason for this is symmetry. It is possible to create a tree of folders (using "mkdir(parents=True)"), but once you do that you cannot remove it again in a straightforward way.
3. newLine for write_text
This is the only relevant option that "Path.open" has but "Path.write_text" doesn't, and is a serious omission when dealing with multiple operating systems.
4. uid and gid
You can get the owner and group name of a file (with the "owner" and "group" methods), but there is no easy way to get the corresponding number.
5. Stem with no suffixes
The stem property only takes off the last suffix, but even in the example given ('my/library.tar.gz') it isn't really useful because the suffix has two parts ('.tar' and '.gz'). I suggest another property, probably called "rootstem" or "basestem", that takes off all the suffixes, using the same logic as the "suffixes" property. This is another symmetry issue: it is possible to extract all the suffixes, but not remove them.
6. with_suffixes
Equivalent to with_suffix, but replacing all suffixes. Again, this is a symmetry issue. It is hard to manipulate all the suffixes right now, as the example show. You can add them or extract them, but not change them without doing several steps.
7. exist_ok for is_* methods
Currently all the is_* methods (such as is_file) return False if the file doesn't exist or if it is a broken symlink. This can be dangerous, since it is not trivially easy to tell if you are dealing with the wrong type of file vs. a missing file. And it isn't obvious behavior just from the method name. I suggest adding an "exist_ok" argument to all of these, with the default being "True" for backwards-compatibility. This argument name is already in use elsewhere in pathlib. If this is False and the file is not present, a "FileNotFoundError" is raised.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YEN7UA... Code of Conduct: http://python.org/psf/codeofconduct/
I really like these ideas. Effectively, we can use pathlib.Path without ever needing to import shutil. We would like also copyfile from shutil if we are only interested copying the file data. How about adding append_text and append_bytes with newLine similar to what you suggested?
There have been proposals to make pathlib provide ALL file-related operations, but that is not this proposal. shutil would still provide a lot of more advanced functionality. So I think just one operation, copying the file in the least destructive manner possible (probably equivalent to copy2). I wouldn't use "append_text" or "append_bytes" since you can use "open" for something like that. Sincerely, Todd On Sun, Nov 22, 2020 at 3:27 PM Abdulla Al Kathiri < alkathiri.abdulla@gmail.com> wrote:
I really like these ideas. Effectively, we can use pathlib.Path without ever needing to import shutil. We would like also copyfile from shutil if we are only interested copying the file data. How about adding append_text and append_bytes with newLine similar to what you suggested?
On Nov 22, 2020, at 11:53 PM, Todd <toddrjen@gmail.com> wrote:
I know enhancements to pathlib gets brought up occasionally, but it doesn't look like anyone has been willing to take the initiative and see things through to completion. I am willing to keep the ball rolling here and even implement these myself. I have some suggestions and I would like to discuss them. I don't think any of them are significant enough to require a pep. These can be split it into independent threads if anyone prefers.
1. copy
The big one people keep bringing up that I strongly agree on is a "copy" method. This is really the only common file manipulation task that currently isn't possible. You can make files, read them, move them, delete them, create directories, even do less common operations like change owners or create symlinks or hard links.
A common objection is that pathlib doesn't work on multiple paths. But that isn't the case. There are a ton of methods that do that, including:
* symlink_to * link_to * rename * replace * glob * rglob * iterdir * is_relative_to * relative_to * samefile
I think this is really the only common file operation that someone would need to switch to a different module to do, and it seems pretty strange to me to be able to make symbolic or hard links to a file but not straight up copy one.
2. recursive remove
This could be a "recursive" option to "rmdir" or a "rmtree" method (I prefer the option). The main reason for this is symmetry. It is possible to create a tree of folders (using "mkdir(parents=True)"), but once you do that you cannot remove it again in a straightforward way.
3. newLine for write_text
This is the only relevant option that "Path.open" has but "Path.write_text" doesn't, and is a serious omission when dealing with multiple operating systems.
4. uid and gid
You can get the owner and group name of a file (with the "owner" and "group" methods), but there is no easy way to get the corresponding number.
5. Stem with no suffixes
The stem property only takes off the last suffix, but even in the example given ('my/library.tar.gz') it isn't really useful because the suffix has two parts ('.tar' and '.gz'). I suggest another property, probably called "rootstem" or "basestem", that takes off all the suffixes, using the same logic as the "suffixes" property. This is another symmetry issue: it is possible to extract all the suffixes, but not remove them.
6. with_suffixes
Equivalent to with_suffix, but replacing all suffixes. Again, this is a symmetry issue. It is hard to manipulate all the suffixes right now, as the example show. You can add them or extract them, but not change them without doing several steps.
7. exist_ok for is_* methods
Currently all the is_* methods (such as is_file) return False if the file doesn't exist or if it is a broken symlink. This can be dangerous, since it is not trivially easy to tell if you are dealing with the wrong type of file vs. a missing file. And it isn't obvious behavior just from the method name. I suggest adding an "exist_ok" argument to all of these, with the default being "True" for backwards-compatibility. This argument name is already in use elsewhere in pathlib. If this is False and the file is not present, a "FileNotFoundError" is raised.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YEN7UA... Code of Conduct: http://python.org/psf/codeofconduct/