[Python-3000] iostack and Oh Oh

[Paul Moore]

On 11/30/06, Bill Janssen <janssen at parc.com> wrote:
> > so no offense in advance.
>
> Sure, no offense taken.  I've seen comments like this before on this
> list (recently :-).  I think both approaches (interface types and duck
> typing) are complicated in different ways.

Instinctively, I agree with Tomer on this issue. But I'm reasonably
relaxed about the matter as long as it's optional. What I'm not sure
about, is if that is the intention. For example,

    class MyMap:
        def __getitem__(self, key): ...
        def __setitem__(self, key, value): ...

If I pass this into a function (written by a 3rd party, so I have no
way of changing it) that *only* uses the syntax m[k] on it (never
needs to do len(m), or m.keys() or anything else), will it work?
Please note that MyMap is deliberately written to *not* conform to any
of your proposed base classes.

If it doesn't work, then my code is excluded from using a perfectly
good piece of 3rd party code for no reason. Sure, I can "fix" the
problem by implementing a few extra methods (just raising an exception
if they are called) and possibly declaring that I conform to an
interface (which, actually, I don't). But why should I have to?

I appreciate that this is an oversimplified argument, and that
interfaces/ABCs/GFs/whatever have significant value within certain
types of framework - but you're not proposing a hierarchy for
framework-specific classes here, but rather for the fundamental types
of the language.

If the proposed class hierarchy is going to have an impact on code
which is not written around a framework (like Twisted) which is built
on interfaces, the result won't feel like Python to me, as far as I
can see...

Paul.