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

[Nick Coghlan]

On 13 April 2016 at 03:33, Brett Cannon <brett at python.org> wrote:
>
>
> On Tue, 12 Apr 2016 at 10:18 Nikolaus Rath <Nikolaus at rath.org> wrote:
>>
>> On Apr 11 2016, Ethan Furman
>> <ethan-gcWI5d7PMXnvaiG9KC9N7Q at public.gmane.org> wrote:
>> >> As far as I can see, implementing a protocol instead of adding a few
>> >> isinstance checks is more likely to make the life of a CPython
>> >> developer
>> >> harder than easier.
>> >
>> > I disagree.  And the protocol idea was not mine, so apparently other
>> > core-devs also disagree (or think it's worth it, regardless).
>>
>> I haven't found any email explaining why a protocol would make things
>> easier than the isinstance() approach (and I read most of the threads
>> both here and on -dev), so I was assuming that the core-devs in question
>> don't disagree but haven't considered the second approach.
>
>
> I disagree with the idea. :) Type checking tends to be too strict as it
> prevents duck typing. And locking ourselves to only what's in the stdlib is
> way too restrictive when there are alternative path libraries out there
> already. Plus it's short-sighted to assume no one will ever come up with a
> better path library, and so tying us down to only pathlib.PurePath
> explicitly would be a mistake long-term when specifying a single method
> keeps things flexible (this is the same reason __index__() exists and we
> simply don't say indexing has to be with a subclass of int or something).

In addition to these general API design points, there's also a key
pragmatic point, which is that we probably want
importlib._bootstrap_external to be able to use the new API, which
means it needs to work before any non-builtin and non-frozen modules
are available. That's easy with a protocol, hard with a concrete
class.

Most folks don't need to worry about "How we do make this code work
when the interpeter isn't fully configured yet?", but we don't always
have that luxury :)

As for why it wasn't specifically discussed before now, "protocols are
preferable to dependencies on concrete classes" is such an entrenched
design pattern in Python by this point that we tend to take it for
granted, so unless someone specifically asks for an explanation, we're
unlikely to spell it out again. (Thanks for doing that, by the way - I
suspect you're far from the only one that was puzzled by the apparent
omission).

Cheers,
Nick.

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