On 18 March 2018 at 04:41, Nathaniel Smith <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 https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
