[Python-Dev] File system path PEP, part 2

[Brett Cannon]

On Fri, 13 May 2016 at 10:53 Steven D'Aprano <steve at pearwood.info> wrote:

> On Fri, May 13, 2016 at 03:43:29PM +0000, Brett Cannon wrote:
> > On Fri, 13 May 2016 at 04:00 Steven D'Aprano <steve at pearwood.info>
> wrote:
>
> [...]
> > > - but os.fspath() will only return str;
> > > - and os.fspathb() will only return bytes;
>
> > I prefer what's in the PEP. I get where you coming from, Steven, but I
> > don't think it will be common enough to worry about. Think of os.fspath()
> > like next() where it truly is a very minor convenience function that
> > happens to special-case str and bytes.
>
> Okay, I'm satisfied by the various arguments against this idea.
>

I'll add a note in the Rejected Ideas section about this.


>
>
> [...]
> > > I think it is a bit confusing to refer to "path objects", as that seems
> > > like you are referring only to pathlib.Path objects. It took me far too
> > > long to realise that here you mean generic path-like objects that obey
> > > the __fspath__ protocol rather than a specific concrete class.
> > >
> > > Since the ABC is called "PathLike", I suggest we refer to "path-like
> > > objects" rather than "path objects", both in the PEP and in the Python
> > > docs for this protocol.
> > >
> >
> > I went back and forth with this in my head while writing the PEP. The
> > problem with making "path-like" mean "objects implementing the PathLike
> > ABC" becomes how do you refer to an argument of a function that accepts
> > anything os.fspath() does (i.e. PathLike, str, and bytes)?
>
> On further reflection, I think the right language is to use "path-like"
> for the union of Pathlike, str and bytes. That will, I think, cover the
> majority of cases: most functions which want to work on a file system
> path should accept all three. When you want to specify only an object
> which implements the PathLike ABC, that's called a (virtual) instance of
> PathLike.
>
> I see this as analogous to "iterable". An iterable is anything which can
> be iterated over. Sometimes that's an iterator. Sometimes its not an
> iterator. We don't have a special term for "iterable which is not an
> iterator", mostly because its rare to care about the distinction, but on
> those rare cases that we do care, we can describe it explicitly.
>
> In this case, "path-like" would be equivalent to iterable: anything that
> can be used as a file system path. Some path-like objects are actual
> pathlib.Path objects, some are some other PathLike object, and some are
> strings or bytes.
>

That was my general thinking. I'll add a TODO to add an entry in the
glossary for "path-like".


>
>
> [...]
> > > >         try:
> > > >             return path.__fspath__()
> > >
> > > Would I be right in saying that in practice this will actually end up
> > > being type(path).__fspath__() to match the behaviour of all(?) other
> > > dunder methods?
> > >
> >
> > I wasn't planning on it because for most types the accessing of the
> method
> > directly off of the type for magic methods is because of some special
> > struct field at the C level that we're pulling from. Since we're not
> > planning to have an equivalent struct field I don't see any need to do
> the
> > extra work of avoiding the instance participating in method lookup.
> > Obviously if people disagree for some reason then please let me know
> (maybe
> > for perf by avoiding the overhead of checking for the method on the
> > instance?).
>
> The reasons I would disagree are:
>
> (1) It took me a long time to learn the rule that dunder methods are
> always called from the class, not the instance, and now I have to learn
> that there are exceptions? Grrrr argggh.
>
> (2) If we ever do change to a C struct field, the behaviour will change.
> Maybe it's better to emulate the same behaviour from the start?
>
> (3) If there's a performance speed up, that's a bonus!
>

And Guido agrees with this as well so I'll be updating the PEP shortly
after I remember how to do the equivalent from C. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160513/fc780568/attachment-0001.html>