[Python-Dev] File system path PEP, part 2 (original) (raw)

Koos Zevenhoven k7hoven at gmail.com
Fri May 13 15:26:24 EDT 2016

On Fri, May 13, 2016 at 8:52 PM, 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: [...] > 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. >

This terminology is indeed a bit difficult, not least because there are 6 different path classes in pathlib. A couple of months ago, I decided to start to call these pathlib objects and path objects, because I did not know what else to call them without doubling the length.

> 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.

As I've told Brett before, I think exactly this reasoning would be a good enough reason not to call the ABC PathLike.

[...]

> 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.

Who knows, maybe the exception made it take a longer time..

IIRC the docs say that dunder methods are not guaranteed to be called on the instance, because they may be called on the class.

(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!

-- Steven

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com

More information about the Python-Dev mailing list