[Python-ideas] New PEP proposal -- Pathlib Module Should Contain All File Operations

[Jason Maldonis]

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 <p.f.moore at gmail.com> wrote:

> On 18 March 2018 at 04:41, Nathaniel Smith <njs at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180318/80e8b847/attachment-0001.html>