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

Paul Moore p.f.moore at gmail.com
Fri Dec 1 10:17:49 CET 2006

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.

More information about the Python-3000 mailing list