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 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. [...] > > > 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! -- Steven _______________________________________________ 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
