[Python-Dev] Defining a path protocol

Chris Barker - NOAA Federal chris.barker at noaa.gov
Wed Apr 6 20:43:42 EDT 2016

>> Ah, good point. I think that kills __path__ then as an option.

Darn. I really preferred that. Oh well.

> __fspath__


But not a big deal. I think this is pretty much for occasional use by
library authors, so not a big deal what it is named.

Which also means that I don't think we need a built-in function that
calls it, either. How often do people need a stringified-path version
of an arbitrary object?

Which makes me think: str() calls __str__ on an arbitrary object, and
creates a new string object.

But fspath(), if it exists, would call __fspath__ on an arbitrary
object, and create a new string -- not a new Path. That may be

If we were starting from scratch, I suppose __path__ would return a
Path object -- it would be a protocol one could use to duck-type a

But since we have history, we are creating a protocol that conforms to
the existing string-as-path protocol.

So are we imagining that future libs will be written that only take
objects with a __fspath__ method? In which case, do we need to add it
to str? In which case, this is all kind of pointless.

Or maybe all future libs will continue to accept either an str or an
object with __fspath__.  In which case, this is pretty pointless, too.

I guess what I'm wondering is if we are stuck with str-paths as the
lingua-Franca for paths forever. In which case, we should embrace that
and just call str() on anything passed in as a path argument.

Sure, then open(3.5) will give you a file not found error, or maybe
create a file with a weird name, but really? Who's going to make that
mistake and not figure it out really quickly?


More information about the Python-Dev mailing list