<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>