<div dir="ltr">Maybe this is obvious or I am missing something crucial, but I'm surprised that this hasn't been discussed yet:<br><br>From a user perspective, imo the problem is that users currently need three modules (pathlib, os, and shutil) to have a nice interface for working with, copying, and removing files. In general, it seems to me that there should be two modules for file-like operations: a fast, low-level module, and a (slower) high-level module that provides a more natural interface than the low-level module. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">It seems natural that the high-level module should simply use the low-level module to do the file operators, and just provide a nice (probably object-oriented) interface for those methods.</span><div><br></div><div>In python, `os` and `shutil` are currently the low-level modules, and it stands to reason that we might consider combining these somehow (although I'm assuming that there was a good reason not to in the first place, which is why they both exist, but I haven't looked into it). And `pathlib` is currently the "high-level" module.</div><div><br></div><div>I see two problems currently:</div><div><br></div><div>1) the low-level module is split in half (for example, operations for copying are contained in `shutil` and operations for removing are contained in `os`). This is a bit annoying for the user, but it's not game-breaking. It does, however, make python feel a bit unnatural in this context, and that's even more unusual because normally python feels very natural. So this becomes sort of a "huh this feels weird" situation.</div><div><br></div><div>2) The `pathlib` modules only provides a high-level interface for working with _single_ Path objects. There isn't really functionality to work with multiple Path objects (as pointed out by someone previously if I am understanding correctly).<br><div><br></div><div>I don't think the current PEP under consideration adequately solves either of these problems. Currently, it seems like it's trying to make `pathlib` both a high- and low-level module, which imo doesn't make sense.</div><div><br></div><div>But I do think we need, if not a single low-level module, at least a high-level module that makes it unnecessary to use the low-level modules. That means that `pathlib` needs more functionality added to it, which is similar in spirit to the current PEP proposal.</div><div><br></div><div>- Jason, a reader<br><div><br></div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 18, 2018 at 9:46 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 18 March 2018 at 04:41, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> My understanding is that the point of Path is to be a convenient,<br>
> pleasant-to-use mechanism for accessing common filesystem operations.<br>
> And it does a pretty excellent job of that. But it seems obvious to me<br>
> that it's still missing a number of fairly basic operations that<br>
> people need all the time.<br>
<br>
</span>IMO, the pathlib module (just) defines Path. So I'm -1 on adding<br>
anything to pathlib that isn't a method of a Path object. Beyond that,<br>
I agree with you that Path should be a convenient interface for<br>
filesystem path objects. I haven't personally found that there's much<br>
missing that I've needed, but I agree that there are some gaps from a<br>
theoretical point of view, and adding methods to fill those gaps could<br>
be justifiable. OTOH, the fspath protocol was explicitly designed so<br>
that standalone functions (such as the ones in os and shutil) can work<br>
cleanly with Path objects - so there's a strong argument that "not<br>
everything needs to be a method" applies here. For example, while<br>
there isn't a Path.makedirs(), what's so bad about os.makedirs(Path)?<br>
(There's consistency and discoverability arguments, but they are not<br>
what I'd call compelling on their own).<br>
<span class=""><br>
> I don't think the PEP is there yet, and we<br>
> can quibble over the details -- just copying over all the historical<br>
> decisions in shutil isn't obviously the right move (maybe it should be<br>
> Path.mkdir(include_parents=<wbr>True) and Path.unlink(recursive=True)<br>
> instead of Path.makedirs and Path.rmtree?), but there's definitely<br>
> room for improvement.<br>
<br>
</span>I agree that there are some potential candidates for "useful<br>
additional methods for Path objects", but I'd like to see these<br>
discussed on a case by case basis, much like you do here, rather than<br>
as a blanket "if it's in some other module and it works on paths, it<br>
should be in pathlib.<br>
<br>
My biggest problem with the proposal as it stands is that it makes no<br>
attempt to justify the suggestions on a case by case basis (the first<br>
version wasn't even explicit in the functions it was proposing!) but<br>
argues from a pure "lump everything together" standpoint.<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>