[Python-ideas] Better stdlib support for Path objects

[Ethan Furman]

On 10/07/2014 07:24 AM, Barry Warsaw wrote:
> On Oct 07, 2014, at 02:55 PM, Paul Moore wrote:
>>
>> I find it worse than a disincentive, it makes understanding the code
>> perceptibly harder, which is a maintenance issue. Having an attribute
>> that returns the string representation would be a substantial
>> improvement (as it's the extra parentheses from the str call that I
>> find the most distracting, that and the code smell that an "explicit
>> cast" involves).
>
> I realize there's another thing that bugs me about sprinkling str() calls all
> over the place, and this relates to my other question about whether
> str()-ability is "the path protocol".
>
> The problem is that if I'm looking at some random code and see:
>
>      my_parser.load(str(path))
>
> I really don't have any idea what 'path' is.  Maybe that's a good thing, but
> in the few cases where I did this, it seemed bad. ;)
>
> OTOH, if I saw this, it would be a strong clue that path were a pathlib
> object:
>
>      my_parser.load(path.string_path)
>
> substituting .string_path for whatever color the shed gets painted.

Neither should be needed:

     my_parser.load(path)

should do the trick.

What was the point of adding pathlib to the stdlib if we cannot use it with the stdlib?

Having a __strpath__ and/or __bytespath__ would also allow third-party path libraries to be utilized.

--
~Ethan~