[Python-ideas] abc.optionalabstractmethod

[Nick Coghlan]

On Tue, Aug 7, 2012 at 4:51 PM, James William Pye <x at jwp.io> wrote:
> On Aug 6, 2012, at 10:02 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> No. That leads to a combinatorial explosion of interface classes that
>> only makes sense in languages which don't readily support attribute
>> level introspection (*cough*such-as-Java*cough*).
>
> Yes, so don't do that. =)
>
> What's the matter with having a set of *distinct* interface classes and having
> a given *implementation* cherry pick the appropriate ones?

If the additional ABCs are defined with an appropriate fallback to a
method existence check (ala collections.Hashable) then it may be OK.
However, the long "implements" lists that Java is prone to is
precisely the boilerplate I consider unacceptable (and antithetical to
ducktyping).

The point of this discussion is that there really isn't an obvious
general purpose mechanism that easily lets you document the existence
of an optional method in an ABC (such that tools like pydoc will see
it), without inadvertently making it look like that method is
implemented. The "x.__hash__ is None" trick that is used to get around
object.__hash__ existing by default certainly works, but is definitely
not the typical behaviour. Other approaches, like returning
NotImplemented or raising NotImplementedError have the problem that
the only way to find out if they're implemented or not is to call
them, which may have unwanted side effects if they *are* implemented.

That's why the IO stack has methods like "seekable()" - to ask the
question "is the seek() method implemented?".

Cheers,
Nick.


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