[Python-3000] iostack and Oh Oh

[Guido van Rossum]

On 12/1/06, Paul Moore <p.f.moore at gmail.com> wrote:
> 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.

It would still work, *unless* the code that receives this object does
an explicit check for whether its argument implements some Mapping
interface or ABC.

> 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?

If the 3rd party code makes it part of its API requirements that you
must only pass it an object that implements a certain interface, then
you had better conform to that requirement. The 3rd party code may
have a plan for evolving the implementation in such a way that
eventually it *will* require all the functionality of that interface,
and they would prefer that you are warned of this possibility in
advance.

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

The proposal provides a better way to check whether something
implements a particular interface. It doesn't propose adding any
automatic type checking to the language.

If you were writing a framework today, and you had to design an API
that took either a sequence or a mapping -- how would you distinguish
the two? Both implement __getitem__, __iter__ and __len__. Would you
test for the presence of a keys() method, even if you have no need to
ever call it? What makes keys() special? With interfaces or ABCs, you
can test whether it implements the Mapping or Sequence API (or some
more primitive base for those).

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

Of course. And nobody is proposing that.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)