[Python-ideas] pathlib suggestions

[Todd]

On Wed, Jan 25, 2017 at 12:25 AM, Stephen J. Turnbull <
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.


>  > a "nosuffix" extension to return the path without any extensions,
>
> +1      (subject to name bikeshedding) .suffixes itself is kinda
>         useless without this, and you shouldn't have to roll your own
>
> Do you propose to return a Path or a str here?
>

I intend it to behave as much as possible like the existing "stem"
property, so a string.


>
>  > and a "with_suffixes" method that replaces all the suffix and can
>  > accept multiple arguments (which would then be joined to create the
>  > extensions).
>
> Do you propose to return a Path or a str here?  +1 for a Path, +0 for
> a str.
>

It is intended to behave as much as possible like the existing "with_suffix"
method, so a Path.


>  > Second, for methods like "rename" and "replace", it would be nice if
> there
>  > was an "exist_ok" argument that defaults to "True" to allow for safe
>  > renaming.
>
> -1      I don't see how this is an improvement.  If it would raise if
>         exist_ok == False, then
>
>     try:
>         p.rename(another_p, exist_ok=False)
>     except ExistNotOKError:
>         take_evasive_action(p)
>
> doesn't seem like a big improvement over
>
>     if p.exists():
>         take_evasive_action(p)
>     else:
>         p.rename(another_p)
>
> And if it doesn't raise, then the action just silently fails?
>
>

As Ed said, this can lead to race conditions.  Something could happen after
you check "exists".

Also, the "mkdir" method already has an "exist_ok" argument, and the "open"
function has the "x" flag to raise an exception if the file already
exists.  It seems like a major omission to me that there are safe ways to
make files and safe ways to make directories, but no safe way to move files
or directories.


> Name bikeshedding: IIRC, if an argument is essentially always going to
> be one of a small number of literals, Guido strongly prefers a new
> method (eg, rename_safely).
>
>
File and directory handling is already full of flags like this.  This
argument was taken verbatim from the existing "mkdir" method for
consistency.


>
>  > Fourth, for the "is_*" methods, it would be nice if there was a "strict"
>  > argument that would raise an exception if the file or directory doesn't
>  > exist.
>
> -1 That seems weird in a library intended for the syntactic
> manipulation of uninterpreted paths (even though this is a semantic
> operation).  TOOWTDI and EIBTI, as well.  For backward compatibility,
> strict would have to default to False.
>
>
First, these methods only exist for "concrete" paths, which are explicitly
intended for use in I/O operations.

Second, as before, this argument is taken from another method.  In this
case, the "resolve" method has a "strict" argument.  Any other approach
suffers from the same race conditions as "rename" and "replace", and again
it seems weird that resolving a path can be done safely but testing it
can't be.

And yes, the argument would have to default to "False".  All of my
suggestions are intended to be completely backwards-compatible.  I don't
see that as a problem, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170125/9f629bc7/attachment.html>