[Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 05:43 PM, Chris Barker - NOAA Federal wrote:

>> __fspath__
>
> +0.1
>
> 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.

It's mostly for the stdlib itself.  I imagine that most libraries would 
just take what they are given and pass it along to open or os.stat or 
whatever.

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

Not often.

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

It would be more along the lines of pickle -- give me the standard 
serialized form of this Path, please.

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

Sure.

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

Yup.

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

We are imagining that future libraries that have to muck about with 
paths will work with Path objects, either by accepting them or 
converting to them as the (possibly) stringified paths are passed in -- 
and when necessary those libs can pass either the Path obj or the 
stringified path to the stdlib.

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

The point is to allow future programs to work with Path and be able to 
work with the stdlib as seamlessly and painlessly as possible.

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

Nah.  That's inviting trouble and pain, and we're trying to get away 
from that.

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

Well, since the 3.5 was actually in my_var, and could have been written 
before it was read, it could easily be days, weeks, or even months -- 
probably after the last guy quit, you took the job, the server died, and 
you had to restore from backup -- at which point you'll see all the 
really, really strange file names and wonder what they are.  And of 
course, whatever logic was determining those weird names is now out of 
sync because of the server swap.

And, yeah, I've seen weirder things happen.

--
~Ethan~