> On 18 Mar 2018, at 17:50, Jason Maldonis <jjmaldo...@gmail.com> wrote: > > Maybe this is obvious or I am missing something crucial, but I'm surprised > that this hasn't been discussed yet: > > 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. 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. > > 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. > > I see two problems currently: > > 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. > > 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). > > 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. > > 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
Surely shutil is a *high* level modules. os is a low level module that shutil builds on. Adding the missing pieces to shutil would make it the place to go to do file operations. Pity its not called filelib. Barry > > - Jason, a reader > > > > > On Sun, Mar 18, 2018 at 9:46 AM, Paul Moore <p.f.mo...@gmail.com > <mailto:p.f.mo...@gmail.com>> wrote: > On 18 March 2018 at 04:41, Nathaniel Smith <n...@pobox.com > <mailto:n...@pobox.com>> wrote: > > My understanding is that the point of Path is to be a convenient, > > pleasant-to-use mechanism for accessing common filesystem operations. > > And it does a pretty excellent job of that. But it seems obvious to me > > that it's still missing a number of fairly basic operations that > > people need all the time. > > IMO, the pathlib module (just) defines Path. So I'm -1 on adding > anything to pathlib that isn't a method of a Path object. Beyond that, > I agree with you that Path should be a convenient interface for > filesystem path objects. I haven't personally found that there's much > missing that I've needed, but I agree that there are some gaps from a > theoretical point of view, and adding methods to fill those gaps could > be justifiable. OTOH, the fspath protocol was explicitly designed so > that standalone functions (such as the ones in os and shutil) can work > cleanly with Path objects - so there's a strong argument that "not > everything needs to be a method" applies here. For example, while > there isn't a Path.makedirs(), what's so bad about os.makedirs(Path)? > (There's consistency and discoverability arguments, but they are not > what I'd call compelling on their own). > > > I don't think the PEP is there yet, and we > > can quibble over the details -- just copying over all the historical > > decisions in shutil isn't obviously the right move (maybe it should be > > Path.mkdir(include_parents=True) and Path.unlink(recursive=True) > > instead of Path.makedirs and Path.rmtree?), but there's definitely > > room for improvement. > > I agree that there are some potential candidates for "useful > additional methods for Path objects", but I'd like to see these > discussed on a case by case basis, much like you do here, rather than > as a blanket "if it's in some other module and it works on paths, it > should be in pathlib. > > My biggest problem with the proposal as it stands is that it makes no > attempt to justify the suggestions on a case by case basis (the first > version wasn't even explicit in the functions it was proposing!) but > argues from a pure "lump everything together" standpoint. > > Paul > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org <mailto:Python-ideas@python.org> > https://mail.python.org/mailman/listinfo/python-ideas > <https://mail.python.org/mailman/listinfo/python-ideas> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/> > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
