<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 11:16 AM, Petr Viktorin <span dir="ltr"><<a href="mailto:encukou@gmail.com" target="_blank">encukou@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 01/25/2017 04:33 PM, Todd wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
On Wed, Jan 25, 2017 at 10:18 AM, Petr Viktorin <<a href="mailto:encukou@gmail.com" target="_blank">encukou@gmail.com</a><br></span><span class="gmail-">
<mailto:<a href="mailto:encukou@gmail.com" target="_blank">encukou@gmail.com</a>>> wrote:<br>
<br>
On 01/25/2017 04:04 PM, Todd wrote:<br>
<br>
On Wed, Jan 25, 2017 at 12:25 AM, Stephen J. Turnbull<br>
<<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank">turnbull.stephen.fw@u.tsukuba<wbr>.ac.jp</a><br>
<mailto:<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank">turnbull.stephen.fw@u.<wbr>tsukuba.ac.jp</a>><br></span>
<mailto:<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank">turnbull.stephen.fw@u.<wbr>tsukuba.ac.jp</a><div><div class="gmail-h5"><br>
<mailto:<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank">turnbull.stephen.fw@u.<wbr>tsukuba.ac.jp</a>>>> wrote:<br>
<br>
I'm just going to let fly with the +1s and -1s, don't take<br>
them too<br>
seriously, they're basically impressionistic (I'm not a huge<br>
user of<br>
pathlib yet).<br>
<br>
Todd writes:<br>
<br>
> So although the names are tentative, perhaps there could be a<br>
"fullsuffix"<br>
> property to return the extensions as a single string,<br>
<br>
-0 '.'.join(p.suffixes) vs. p.fullsuffix? TOOWTDI says<br>
no. I<br>
also don't really see the use case.<br>
<br>
<br>
The whole point of pathlib is to provide convenience functions for<br>
common path-related operations. It is full of methods and<br>
properties<br>
that could be implemented other ways.<br>
<br>
Dealing with multi-part extensions, at least for me, is extremely<br>
common. A ".tar.gz" file is not the same as a ".tar.bz2" or a<br>
".svg.gz". When I want to find a ".tar.gz" file, having to deal<br>
with<br>
the ".tar" and ".gz" parts separately is nothing but a<br>
nuisance. If I<br>
want to find and extract ".rar" files, I don't want ".part1.rar"<br>
files,<br>
".part2.rar" files, and so on. So for me dealing with the<br>
extension as<br>
a single unit, rather than individual parts, is the most common<br>
approach.<br>
<br>
<br>
But what if the .tar.gz file is called "spam-4.2.5-final.tar.gz"?<br>
Existing tools like glob and endswith() can deal with the ".tar.gz"<br>
extension reliably, but "fullsuffix" would, arguably, not give the<br>
answers you want.<br>
<br>
<br>
<br>
I wouldn't use it in that situation. The existing "suffix" and "stem"<br>
properties also only work reliably under certain situations.<br>
</div></div></blockquote>
<br>
Which situations do you mean? It works quite fine with multiple suffixes:<br>
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.<br>
<br></blockquote></div><br><br></div><div class="gmail_extra">A ".tar.gz" is not the same as a ".svg.gz". The fact that they are both gzip-compressed is an implementation detail as far as most software I deal with is concerned. My unarchiver will extract a ".tar.gz" into a directory as if it was just a ".tar", while my image viewer will view a ".svg.gz" as a vector image as if it was just a ".svg". From a user-interaction standpoint, the ".gz" part is ignored.<br></div></div>