[Python-ideas] Better stdlib support for Path objects

[Nick Coghlan]

On 7 October 2014 23:37, 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?
>
> What I'm trying to understand is whether str(argument) is that "path protocol"
> or whether there's a good reason that something else that's specifically not
> str-ification is required.

It's mostly a matter of offering better failure modes - the reasons
would be similar to why we added operator.index and __index__ in order
to expand various APIs from "only int or long objects" without
expanding them so far that they also accepted float objects or strings
the way coercing via "int" would.

Using str(x) implicitly allows lots of nonsense that should throw an
immediate TypeError to instead throw OSError later on (or, worse,
perhaps even appear to work).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia