On Sun, Nov 22, 2020 at 3:27 PM Abdulla Al Kathiri <
alkathiri.abdu...@gmail.com> wrote:
> On Nov 22, 2020, at 11:53 PM, Todd <toddr...@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-le...@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/YEN7UA67INEUGG44R3RWAF2JFHAXZC77/
> 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.abdu...@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 <toddr...@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-le...@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/YEN7UA67INEUGG44R3RWAF2JFHAXZC77/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/PGML2G2DLCX4XKULOAGCUJCZYF7PGQRX/
Code of Conduct: http://python.org/psf/codeofconduct/
