[Python-ideas] Better stdlib support for Path objects

Chris Angelico rosuav at gmail.com
Tue Oct 7 15:45:41 CEST 2014


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?

ChrisA


More information about the Python-ideas mailing list