[Python-ideas] PEP 428 - object-oriented filesystem paths

[Calvin Spealman]

On Mon, Oct 8, 2012 at 1:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Sat, Oct 6, 2012 at 9:44 PM, Calvin Spealman <ironfroggy at gmail.com>
> wrote:
> > Responding late, but I didn't get a chance to get my very strong
> > feelings on this proposal in yesterday.
> >
> > I do not like it. I'll give full disclosure and say that I think our
> > earlier failure to include the path library in the stdlib has been a
> > loss for Python and I'll always hope we can fix that one day. I still
> > hold out hope.
> >
> > It feels like this proposal is "make it object oriented, because
> > object oriented is good" without any actual justification or obvious
> > problem this solves. The API looks clunky and redundant, and does not
> > appear to actually improve anything over the facilities in the os.path
> > module. This takes a lot of things we can already do with paths and
> > files and remixes them into a not-so intuitive API for the sake of
> > change, not for the sake of solving a real problem.
>
> The PEP needs to better articulate the rationale, but the key points are:
> - better abstraction and encapsulation of cross-platform logic so file
> manipulation algorithms written on Windows are more likely to work
> correctly on POSIX systems (and vice-versa)
>

Frankly, for 99% of file path work, anything I do on one "just works" on
the other, and complicating things with these POSIX versus NT path types
just seems to be a whole lot of early complication for a few edge cases
most people never see.

Simplest example is requiring the backslash separator on NT when it handles
forward slash, just like POSIX, just fine, and has for a long, long time.


> - improved ability to manipulate paths with Windows semantics on a
> POSIX system (and vice-versa)
> - better support for creation of "mock" filesystem APIs
>

I admit the mock FS intrigues me


> > As for specific problems I have with the proposal:
> >
> > Frankly, I think not keeping the / operator for joining is a huge
> > mistake. This is the number one best feature of path and despite that
> > many people don't like it, it makes sense. It makes our most common
> > path operation read very close to the actual representation of the
> > what you're creating. This is great.
>
> It trades readability (and discoverability) for brevity. Not good.
>

I thought it had all three. In these situations, where my and another's
perception of a systems strengths and weaknesses are opposite, I don't
really know how to make a good response. :-/

> Not inheriting from str means that we can't directly path these path
> > objects to existing code that just expects a string, so we have a
> > really hard boundary around the edges of this new API. It does not
> > lend itself well to incrementally transitioning to it from existing
> > code.
>
> It's the exact design philosophy as was used in the creation of the
> new ipaddress module: the objects in ipaddress must still be converted
> to a string or integer before they can be passed to other operations
> (such as the socket module APIs). Strings and integers remain the data
> interchange formats here as well (although far more focused on strings
> in the path case).
>
> >
> > The stat operations and other file-facilities tacked on feel out of
> > place, and limited. Why does it make sense to add these facilities to
> > path and not other file operations? Why not give me a read method on
> > paths? or maybe a copy? Putting lots of file facilities on a path
> > object feels wrong because you can't extend it easily. This is one
> > place that function(thing) works better than thing.function()
>
> Indeed, I'm personally much happier with the "pure" path classes than
> I am with the ones that can do filesystem manipulation. Having both
> "p.open(mode)" and "open(str(p), mode)" seems strange. OTOH, I can see
> the attraction in being able to better fake filesystem access through
> the method API, so I'm willing to go along with it.
>
> > Overall, I'm completely -1 on the whole thing.
>
> I find this very hard to square with your enthusiastic support for
> path.py. Like ipaddr, which needed to clean up its semantic model
> before it could be included in the standard library (as ipaddress), we
> need a clean cross-platform semantic model for path objects before a
> convenience API can be added for manipulating them.
>

I somewhat dislike this because I loved path.py so much and this proposal
seems to actively avoid exactly the aspects of path.py that I enjoyed the
most (like the / joining).


> Cheers,
> Nick.
>

path.py was in teh wild, and is still in use. Why do we find ourselves
debating new libraries like this as PEPs? We need to let them play out, see
what sticks. If someone wants to make this library and stick it on PyPI,
I'm not stopping them. I'm encouraging it. Let's see how it plays out. if
it works out well, it deserves a PEP. In two or three years.

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing:
http://www.twitter.com/ironfroggy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121008/eeed2ebb/attachment.html>