[Python-ideas] Updated PEP 428 (pathlib)

[MRAB]

On 2013-03-06 21:18, Andrew Barnert wrote:
> From: "random832 at fastmail.us" <random832 at fastmail.us>
>
> Sent: Wednesday, March 6, 2013 11:15 AM
>
>
>> On Wed, Mar 6, 2013, at 13:28, Andrew Barnert wrote:
>>> The problem is that I think people will still want a
>>> stripext/stem/root/whatever function that removes the extension
>>> without also removing the dirname. In fact, I've got a script
>>> here where one of my coworkers has written $(dirname
>>> $z)/$(basename $z .zip) to get around it.
> …
>
>
>> Well, whatever you do is competing with p[:-len('.gz')]
>
> Only the "remove extension by name" is competing with that. The
> "remove any and all extensions" or "remove 1 extension" or "remove n
> extensions" cases—which I think are more common—are not. Of course
> they _are_ competing with various uses of
> partition/rpartition/split/rsplit. But you could make the same
> argument for everything in a path library—p.dirname() is competing
> with p.rpartition(pathsep)[0], and 'p / 'foo' is competing with p +
> pathsep + 'foo', and so on.
>
> As I understand it, the reason to have a path API is to provide a
> "one way to do it" that's obvious, readable, and hard to get wrong.
> And I think p.stripext('.gz') or p.stripext(2) or p.stripext() are
> better than p[:-len('.gz')] or p.rsplit('.', 2)[0] or
> p.partition('.')[0] in that regard.
>
> Except for the name, which nobody's come up with a good suggestion
> for, and the fact that we probably don't want to cram all three
> versions of the operation into one function, or even necessarily
> support all three at all.
>
>> (and in shell, your co-worker could have done ${z%.zip} in
>> ksh/bash/POSIX) - unless you have an example of an OS where the
>> 'extension' component doesn't simply append at the end (well, I
>> suppose they're not case-sensitive on windows - and how much weird
>> long/short filename stuff does pathlib do on windows?)
>
> Funnily enough, according to a comment, this was intended to handle
> all-caps .ZIP on Windows under cygwin. I don't know if it actually
> works (or, for that matter, if %.zip would have worked), as I don't
> have a Windows box with cygwin installed handy. But that's beside the
> point. The point is that people want a method that removes extensions
> (whether by name or otherwise) that doesn't also remove dirnames. And
> if you force them to come up with such a method themselves, they're
> not necessarily going to come up with a good one. I'm sure if we had
> your extended basename but no stripext, someone would write
> p.dirname()/p.basename('.zip').
>
For some reason, p.basename('.zip') feels 'wrong' to me, but
p.basename() feels OK. Perhaps it's because it's not immediately
obvious what the optional argument is for (or, at least, that's how it
seems to me!).

On the other hand, p.stripext('.zip') feels OK because it suggests
that you're stripping off the '.zip' extension (compare with str.strip),
but would that mean that you'd expect p.stripext() also to strip off
the extension, whatever it was?