On Fri, 13 May 2016 at 10:53 Steven D'Aprano <st...@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 <st...@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. :)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com