[Python-3000] iostack and Oh Oh (original) (raw)

Guido van Rossum guido at python.org
Fri Dec 1 17:17:55 CET 2006

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/)

More information about the Python-3000 mailing list