
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 18 Mar 2018, at 17:50, Jason Maldonis <<a href="mailto:jjmaldonis@gmail.com" class="">jjmaldonis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Maybe this is obvious or I am missing something crucial, but I'm surprised that this hasn't been discussed yet:<br class=""><br class="">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" class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">I see two problems currently:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div><div>Surely shutil is a *high* level modules.</div><div>os is a low level module that shutil builds on.</div><div>Adding the missing pieces to shutil would make it the place to go to do file operations.</div><div>Pity its not called filelib.</div><div class=""><br class=""></div><div class="">Barry</div><div class=""><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">- Jason, a reader<br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sun, Mar 18, 2018 at 9:46 AM, Paul Moore <span dir="ltr" class=""><<a href="mailto:p.f.moore@gmail.com" target="_blank" class="">p.f.moore@gmail.com</a>></span> wrote:<br class=""><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" class="">njs@pobox.com</a>> wrote:<br class="">

> My understanding is that the point of Path is to be a convenient,<br class="">

> pleasant-to-use mechanism for accessing common filesystem operations.<br class="">

> And it does a pretty excellent job of that. But it seems obvious to me<br class="">

> that it's still missing a number of fairly basic operations that<br class="">

> people need all the time.<br class="">

<br class="">

</span>IMO, the pathlib module (just) defines Path. So I'm -1 on adding<br class="">

anything to pathlib that isn't a method of a Path object. Beyond that,<br class="">

I agree with you that Path should be a convenient interface for<br class="">

filesystem path objects. I haven't personally found that there's much<br class="">

missing that I've needed, but I agree that there are some gaps from a<br class="">

theoretical point of view, and adding methods to fill those gaps could<br class="">

be justifiable. OTOH, the fspath protocol was explicitly designed so<br class="">

that standalone functions (such as the ones in os and shutil) can work<br class="">

cleanly with Path objects - so there's a strong argument that "not<br class="">

everything needs to be a method" applies here. For example, while<br class="">

there isn't a Path.makedirs(), what's so bad about os.makedirs(Path)?<br class="">

(There's consistency and discoverability arguments, but they are not<br class="">

what I'd call compelling on their own).<br class="">

<span class=""><br class="">

> I don't think the PEP is there yet, and we<br class="">

> can quibble over the details -- just copying over all the historical<br class="">

> decisions in shutil isn't obviously the right move (maybe it should be<br class="">

> Path.mkdir(include_parents=<wbr class="">True) and Path.unlink(recursive=True)<br class="">

> instead of Path.makedirs and Path.rmtree?), but there's definitely<br class="">

> room for improvement.<br class="">

<br class="">

</span>I agree that there are some potential candidates for "useful<br class="">

additional methods for Path objects", but I'd like to see these<br class="">

discussed on a case by case basis, much like you do here, rather than<br class="">

as a blanket "if it's in some other module and it works on paths, it<br class="">

should be in pathlib.<br class="">

<br class="">

My biggest problem with the proposal as it stands is that it makes no<br class="">

attempt to justify the suggestions on a case by case basis (the first<br class="">

version wasn't even explicit in the functions it was proposing!) but<br class="">

argues from a pure "lump everything together" standpoint.<br class="">

<span class="HOEnZb"><font color="#888888" class=""><br class="">

Paul<br class="">

</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr class="">_________________<br class="">

Python-ideas mailing list<br class="">

<a href="mailto:Python-ideas@python.org" class="">Python-ideas@python.org</a><br class="">

<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank" class="">https://mail.python.org/<wbr class="">mailman/listinfo/python-ideas</a><br class="">

Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank" class="">http://python.org/psf/<wbr class="">codeofconduct/</a><br class="">

</div></div></blockquote></div><br class=""></div>

_______________________________________________<br class="">Python-ideas mailing list<br class=""><a href="mailto:Python-ideas@python.org" class="">Python-ideas@python.org</a><br class="">https://mail.python.org/mailman/listinfo/python-ideas<br class="">Code of Conduct: http://python.org/psf/codeofconduct/<br class=""></div></blockquote></div><br class=""></body></html>