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~
_______________________________________________
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
