On 01/25/2017 04:33 PM, Todd wrote:
On Wed, Jan 25, 2017 at 10:18 AM, Petr Viktorin <encu...@gmail.com
<mailto:encu...@gmail.com>> wrote:
On 01/25/2017 04:04 PM, Todd wrote:
On Wed, Jan 25, 2017 at 12:25 AM, Stephen J. Turnbull
<turnbull.stephen...@u.tsukuba.ac.jp
<mailto:turnbull.stephen...@u.tsukuba.ac.jp>
<mailto:turnbull.stephen...@u.tsukuba.ac.jp
<mailto:turnbull.stephen...@u.tsukuba.ac.jp>>> wrote:
I'm just going to let fly with the +1s and -1s, don't take
them too
seriously, they're basically impressionistic (I'm not a huge
user of
pathlib yet).
Todd writes:
> So although the names are tentative, perhaps there could be a
"fullsuffix"
> property to return the extensions as a single string,
-0 '.'.join(p.suffixes) vs. p.fullsuffix? TOOWTDI says
no. I
also don't really see the use case.
The whole point of pathlib is to provide convenience functions for
common path-related operations. It is full of methods and
properties
that could be implemented other ways.
Dealing with multi-part extensions, at least for me, is extremely
common. A ".tar.gz" file is not the same as a ".tar.bz2" or a
".svg.gz". When I want to find a ".tar.gz" file, having to deal
with
the ".tar" and ".gz" parts separately is nothing but a
nuisance. If I
want to find and extract ".rar" files, I don't want ".part1.rar"
files,
".part2.rar" files, and so on. So for me dealing with the
extension as
a single unit, rather than individual parts, is the most common
approach.
But what if the .tar.gz file is called "spam-4.2.5-final.tar.gz"?
Existing tools like glob and endswith() can deal with the ".tar.gz"
extension reliably, but "fullsuffix" would, arguably, not give the
answers you want.
I wouldn't use it in that situation. The existing "suffix" and "stem"
properties also only work reliably under certain situations.
Which situations do you mean? It works quite fine with multiple suffixes:
The suffix of "pip-9.0.1.tar.gz" is ".gz", and sure enough, you can
reasonably expect it's a gz-compressed file. If you uncompress it and
strip the extension, you'll end up with a "pip-9.0.1.tar", where the
suffix is ".tar" -- and humans would be surprised if it wasn't a tar
archive.
The function can't determine what a particular human would think of as
the full (or "real") suffix in a particular situation -- but I wouldn't
call it unreliable.
Perhaps more specialized tools would be useful, though, for example:
repacked_path = original_path.replace_suffix(".tar.gz", ".zip")
That is helpful if I want to rename, not if I want to (for example)
uncompress a file.
Something like this?
uncompressed = original_path.replace_suffix(".tar.gz", "")
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
