<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 25, 2017 at 12:25 AM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp" target="_blank">turnbull.stephen.fw@u.tsukuba.ac.jp</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">I'm just going to let fly with the +1s and -1s, don't take them too<br>
seriously, they're basically impressionistic (I'm not a huge user of<br>
pathlib yet).<br>
<span class="gmail-"><br>
Todd writes:<br>
<br>
 > So although the names are tentative, perhaps there could be a "fullsuffix"<br>
 > property to return the extensions as a single string,<br>
<br>
</span>-0      '.'.join(p.suffixes) vs. p.fullsuffix?  TOOWTDI says no.  I<br>
        also don't really see the use case.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>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.  <br><br>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.  <br></div><div> </div><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-">
 > a "nosuffix" extension to return the path without any extensions,<br>
<br>
</span>+1      (subject to name bikeshedding) .suffixes itself is kinda<br>
        useless without this, and you shouldn't have to roll your own<br>
<br>
Do you propose to return a Path or a str here?<br></blockquote><div><br></div><div>I intend it to behave as much as possible like the existing "stem" property, so a string.<br></div><div> </div><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-"><br>
 > and a "with_suffixes" method that replaces all the suffix and can<br>
 > accept multiple arguments (which would then be joined to create the<br>
 > extensions).<br>
<br>
</span>Do you propose to return a Path or a str here?  +1 for a Path, +0 for<br>
a str.<span class="gmail-"><br></span></blockquote><div><br></div><div>It is intended to behave as much as possible like the existing "<code class="gmail-descname">with_suffix" method, so a Path.<br></code></div><div> </div><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-">
 > Second, for methods like "rename" and "replace", it would be nice if there<br>
 > was an "exist_ok" argument that defaults to "True" to allow for safe<br>
 > renaming.<br>
<br>
</span>-1      I don't see how this is an improvement.  If it would raise if<br>
        exist_ok == False, then<br>
<br>
    try:<br>
        p.rename(another_p, exist_ok=False)<br>
    except ExistNotOKError:<br>
        take_evasive_action(p)<br>
<br>
doesn't seem like a big improvement over<br>
<br>
    if p.exists():<br>
        take_evasive_action(p)<br>
    else:<br>
        p.rename(another_p)<br>
<br>
And if it doesn't raise, then the action just silently fails?<br>
<br></blockquote><div><br><br></div><div>As Ed said, this can lead to race conditions.  Something could happen after you check "exists".<br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Name bikeshedding: IIRC, if an argument is essentially always going to<br>
be one of a small number of literals, Guido strongly prefers a new<br>
method (eg, rename_safely).<br>
<br></blockquote><div><br></div><div>File and directory handling is already full of flags like this.  This argument was taken verbatim from the existing "mkdir" method for consistency.<br></div><div> <br></div><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-"><br>
 > Fourth, for the "is_*" methods, it would be nice if there was a "strict"<br>
 > argument that would raise an exception if the file or directory doesn't<br>
 > exist.<br>
<br>
</span>-1 That seems weird in a library intended for the syntactic<br>
manipulation of uninterpreted paths (even though this is a semantic<br>
operation).  TOOWTDI and EIBTI, as well.  For backward compatibility,<br>
strict would have to default to False.<br>
<span class="gmail-"><br></span></blockquote><br></div><div class="gmail_quote">First, these methods only exist for "concrete" paths, which are explicitly intended for use in I/O operations.<br><br>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.<br><br></div><div class="gmail_quote">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.<br></div><br></div></div>