[Python-ideas] Better stdlib support for Path objects

[Andrew Barnert]

On Oct 7, 2014, at 7:40, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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).

The "worse" case would be pretty common. Any API that writes files would just try to create a file named str(path), and on most POSIX platforms that would succeed for almost anything--bytes, int, TextIOWrapper, list of paths that you forgot to open in a listcomp, sequence of chars that you forgot to ''.join, function that you meant to call instead of just referencing, arbitrary generic-repr'd or constructor-repr'd instance, ... Most of my memories of Alpha (a Tcl-programmable classic Mac text editor) are of debugging and cleaning up after errors exactly like this. It would be even more fun for novices trying to figure out how to pass names with angle brackets and quotes to find or rm in a shell they barely know how to use...