On 4/2/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > I am not suggesting the default be that everything satisfies a > protocol. I am thinking about situations like our __index__ > situation; will someone have to explicitly somewhere say that a type > meets the index protocol even if it does implement the __index__ > method?
I guess that should be possible, in some way. You'd need to: 1. Register the fact that the "org.python.index" protocol is equivalent to "has a __index__ method" 2. Make the adapt() function consider (1) above, as well as the usual registry. You might need to consider issues like types that implement an inappropriate method called __index__, but I guess that's not new - you have that with the current __index__ protocol (but you wouldn't have it with an explicit registration scheme, so maybe it's relevant anyway). So yes, it's possible, but it may not be a gain in practice. I suppose this comes into the category of "potential optimisations" Alex talks about. "Real life" implementations of adaptation certainly include convenience stuff like this - PyProtocols includes a number of ways of saying that a class provides an interface, or an interface is directly supported by certain classes. You could probably make PyProtocols understand that "having a method called __index__" implies "supports IIndex" (although it may take some black magic). This is all in the "real life baggage" area that makes adaptation seem harder than Alex's basic example. Is it useful? Maybe. Useful enough to add complexity to the adaptation spec? Again, maybe. How much complexity? Enough to make the thing incomprehensible again? Who knows...? > Basically, as long as I don't have to put much effort into making this > work for the common case where I just inherently implement a protocol > (such as iterators) then I am definitely interested in this. Does adding something like "implements(IIterator)" to your class count as "not much effort"? That's pretty normal for most adaptation implementations I've seen... Paul. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
