On 12/1/06, Paul Moore <[EMAIL PROTECTED]> wrote: > On 11/30/06, Bill Janssen <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
