[Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 08:50 PM, Chris Barker wrote:
 > On Wed, Apr 6, 2016 at 5:57 PM, Ethan Furman wrote:

 >> 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.
 >
 > Exactly -- so we really don't need a builtin shortcut.

Hey, we have to program the stdlib too!  No need to make it harder for 
ourselves.


 >> It would be more along the lines of pickle -- give me the standard
 >> serialized form of this Path, please.
 >
 > well, give me the standard serialized-path of this arbitrary object,
 > yes?

Yes.  :)


 >> 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.
 >
 > if that's the case, we don't need the __fspath__ protocol -- then
 > reason for the protocol is that we imagine there may be any number of
 > third-party objects to represent/work-with paths, that aren't strings
 > or stdlib Path objects.

The purpose of the __os_path__ method is two-fold:

- it's presence declares that the object is a path (or convertible
   to one)
- it does the conversion

Since we need it for ourselves there's no reason to prevent others
from taking advantage of it.


 >> 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.
 >
 > again, we don't need a new protocol for that -- we only need the
 > protocol if we want arbitrary future programs to work with arbitrary
 > path implementations.

I am certainly not opposed to that.

 > which I suppose we do -- there are already other path implimentaitons
 > out there (though at least some are strings :-) )

Right.  And I'm already making changes to mine to work with this
new stuff.


 > People can totally screw up path variables as strings or Path objects
 > too -- I'm having trouble seeing that this is all that more likely --
 > after all, python is a dynamic language -- if we wanted full type
 > safety, we wouldn't be using python...

Very True.  ;)

 > Speaking of which, how is this going to work with the new type
 > system?  Do we need an ABC, rather than just a protocol?

I do not know, good question.

 > But as long as we get to the stdlib taking Path objects, I'm happy :-)

Excellent!

--
~Ethan~