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. - Jason, a reader On Sun, Mar 18, 2018 at 9:46 AM, Paul Moore <[email protected]> wrote: > On 18 March 2018 at 04:41, Nathaniel Smith <[email protected]> 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 > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
