Greg Ewing wrote: > Not very well, IMO. > > Without seeing a concrete use case, it's hard to be > sure, but my feeling is that there's almost certainly > a better way of thinking about the problem you're > trying to solve -- one that doesn't require introspecting > on a callable object to find out whether its implementation > involves a 'self' argument. That's *not* duck typing, > it's look-inside-before-you-leap.
>From the Python Tutorial glossary: ---------- duck-typing Pythonic programming style that determines an object's type by inspection of its method or attribute signature rather than by explicit relationship to some type object ("If it looks like a duck and quacks like a duck, it must be a duck.") By emphasizing interfaces rather than specific types, well-designed code improves its flexibility by allowing polymorphic substitution. Duck-typing avoids tests using type() or isinstance(). Instead, it typically employs hasattr() tests or EAFP programming. ---------- That's what the code is doing. By wrapping the attribute access in a try statement, it is essentially performing a hasattr() test. That is all hasattr does anyway; it tries getattr and checks if an exception occurs. So the question becomes, what is the 'duck test' for objects returned by descriptors? The test used in the example code works with Python 2.5, but fails in only one case in Python 3.0, because unbound methods were removed. When writing a wrapper that might wrap static methods or instance methods (with class binding), the distinction between them disappears when the attribute signature is the same for the the respective callable objects. As for a more concrete example, imagine the wrapper using the inspect module to gather some information about the stack frame and passing it along to selected methods. I just like flexibility, and that's what unbound methods permitted in 2.5. With them, the attribute signature of callable objects is distinct for three separate cases: static methods, instance methods with instance binding, and instance methods with class binding (class methods are just a subset of instance methods with instance binding). I'm not saying that unbound methods are 100% essential--I can learn to live without them--I just think they provided some additional flexibility, and that's a good thing in my opinion. _______________________________________________ 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