[Python-ideas] Better stdlib support for Path objects

[Wolfgang Maier]

On 07.10.2014 15:45, Chris Angelico wrote:
> On Wed, Oct 8, 2014 at 12:37 AM, Barry Warsaw <barry at python.org> wrote:
>> On Oct 07, 2014, at 11:34 AM, Antoine Pitrou wrote:
>>
>>> IMO it's reasonable, but assuming we devise a dedicated protocol for
>>> getting a path's representation (e.g. __strpath__). Concrete type
>>> checking should be avoided.
>>
>> What would __strpath__ do that __str__ wouldn't do?  Or do you think it's
>> better to explicitly disallow str-like objects that aren't path objects?
>
> Currently, __str__ will happily return a string representation of
> basically anything. More generally than __strpath__, maybe what's
> needed is a method "give me a str that accurately represents this
> object", to be provided only by those types which are "virtually
> strings". It'd be an alternative to subclassing str, as a means of
> saying "I'm a string!".
>
> Or maybe this should be done as a collections.abc - there's
> ByteString, maybe there should be TextString. Then anything that
> registers itself as a TextString should be assumed to function as a
> string, and a path could just register itself.
>
> Would that make more sense than __strpath__ does?
>

I think so, but I wouldn't call that ABC TextString, but Path since 
that's what it is and modules wishing to accept str in addition to 
pathlib objects should register str as a Path.

Wolfgang