[Python-Dev] Defining a path protocol (original) (raw)
Ethan Furman ethan at stoneleaf.us
Thu Apr 7 00:15:19 EDT 2016
- Previous message (by thread): [Python-Dev] Defining a path protocol
- Next message (by thread): [Python-Dev] Defining a path protocol
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] Defining a path protocol
- Next message (by thread): [Python-Dev] Defining a path protocol
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]