[Python-ideas] pathlib suggestions

[Todd]

On Wed, Jan 25, 2017 at 11:16 AM, Petr Viktorin <encukou at gmail.com> wrote:

> On 01/25/2017 04:33 PM, Todd wrote:
>
>> On Wed, Jan 25, 2017 at 10:18 AM, Petr Viktorin <encukou at gmail.com
>> <mailto:encukou at 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.fw at u.tsukuba.ac.jp
>>         <mailto:turnbull.stephen.fw at u.tsukuba.ac.jp>
>>         <mailto:turnbull.stephen.fw at u.tsukuba.ac.jp
>>
>>         <mailto:turnbull.stephen.fw at 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.
>
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170125/41b5daf4/attachment.html>