[Python-ideas] Dunder method to make object str-like

Paul Moore p.f.moore at gmail.com
Thu Apr 7 16:46:11 EDT 2016

On 7 April 2016 at 21:28, Ethan Furman <ethan at stoneleaf.us> wrote:
> In case there's any confusion: by "not work" I mean the stdlib is not going
> to correctly interpret a pathlib.Path in 3.3 and earlier.

I think the confusion is over *who* will be checking the protocol or
the ABC. You're correct that the stdlib will not do so in earlier
versions. I've been assuming that is obvious (and I suspect Brett has
too). Talk about using the check for older versions is basically
around the possibility that 3rd party libraries might do so. I think
it's unlikely that they'll bother (but I'm commenting on the
suggestion because I'd like it to be easy to do if anyone does want to
bother, against my expectations). I have the feeling Brett might think
that it's somewhat more likely.

If all we're thinking about is a way for the stdlib to work with
strings and pathlib objects seamlessly, while also allowing 3rd party
path classes to register to be treated the same way, then yes, there's
no real difference between an ABC and a protocol (well, to register
with the ABC, 3rd party code would need to conditionally import the
ABC and make sure not to fail if the ABC can't be found, but that's
just some boilerplate).

Frankly, if it wasn't for the fact that you have stated that you'll
add support for the protocol to your path library, I'd be surprised if
*any* 3rd party code changed as a result of this discussion. There's
been no comment from the authors of path.py or pylib (the only other 2
path objects I know of). And the only comments I've heard from authors
of libraries that consume paths is "I don't see any reason why I'd
bother". So as long as you're happy with the final form of the
proposal, I see little reason to worry about how other 3rd party code
might use it.


More information about the Python-ideas mailing list