In article <[EMAIL PROTECTED]>, S?bastien Boisg?rault wrote: [snip] > Agreed. Consistency matters. But precisely because Python looks in > the type of the object (and not the object itself), I don't need to > explicitely check the type myself: the code adapt = > getattr(protocol, '__adapt__') will find the method > type(protocol).__adapt__ anyway.
This misses the point! :) If you re-read my explanation, perhaps you'll see the difference, but I'll try to state it differently, again using the __call__ example (because it is a very clear case). Let's say we have a class A (a subtype of object, say) which implements a __call__ method. Now, we call this object (that is, the class-object) in order to create instances. Your approach (described in your paragraph above) would be: call = getattr(A, '__call__') a = call() Now, this is clearly wrong. A.__call__ is *not* what we want to call here; that is, after all, only meant to define the behavior of *instances* (i.e., the behavior of a(), in this case). What we *do* want to call is object.__call__ -- and the only way of getting that here, would be the equivalent of this: call = getattr(type(A), '__call__') a = call() So there is a need to *explicitly* bypass the attributes of the object itself and do a lookup *directly* in its type when looking for special methods (as opposed to normal methods). [snip] > Finally, the code >adapt = getattr(protocol, '__adapt__') would work: > 1. if protocol is the instance of a class that implements > __adapt__, Not if the instance itself has an attribute/method with the name __adapt__, in which case your code (again, erroneously IMO) would use that. > 2. if protocol is a class that implements __adapt__. Yes, but then it would use protocol.__adapt__ -- which you don't want, unless you want to break consistency. This would be like using protocol.__call__ to instantiate protocol (which is *not* how things work). [snip] >Agreed. But I'd like to use the classes directly :) ... and you're >right it is mainly a matter of taste. I feel that a class *is* a >kind of protocol ... Yes, I can agree with you there. But I don't see any problems adapting objects to classes... The problem lies in using an objects own attributes as special methods (in this case, the attributes of a class object). Buuut... Then again, a foolish consistency is the hobgoblin of little minds -- or something. I guess if it is useful to use the __adapt__ method of a class in order to adapt objects to it, then one could certainly argue that it's worth breaking the rule that applies to other magic methods... >Have you read the BDFL's "Python Optional Typechecking Redux" ? Yes. >(http://www.artima.com/weblogs/viewpost.jsp?thread=89161) >It's usage of adapt assumes that "a class is a protocol", so I >guess that it does not work with the new version of PEP 246. Why not? There's nothing wrong with classes (or anything else) being protocols...? AFAIK, the current version of the PEP was specifically rewritten in order to fit the BDFL blog (as stated in the PEP). [snip] I don't quite see the conflict (between the blog and the PEP) here... -- Magnus Lie Hetland Time flies like the wind. Fruit flies http://hetland.org like bananas. -- Groucho Marx -- http://mail.python.org/mailman/listinfo/python-list
