One of the best type features of Go is the lack of need to do something like this: "@implements(IEatable)". If a class implements all of the methods of the interface, then it automatically implements that interface. Yuppy seems like a step backwards in OO in this regard.
Perhaps this is an unpopular opinion, but I think the Duck typing philosophy of Python is a feature, not a bug. Imposing the verbosity and rigidity of Java-style OO onto Python seems like a step backwards to me.
I feel like one of the merits of python is the looseness of classes and multiple inheritance. You get the benefits of OO without some of the pitfalls. Sure, you can go through the effort of defining an abstract class but it often isn't needed since your object is often composed of a bunch of separate objects - dealing with a formal contract to some 'abstract' version of your object just adds boilerplate and ends up creating convoluted class hierarchies.
This is very reminiscent of zope.interface used in Twisted. I wouldn't want to argue for or against it, but I've had times when something like this might have been useful in large code bases.<p>[1]: <a href="http://docs.zope.org/zope.interface/" rel="nofollow">http://docs.zope.org/zope.interface/</a>
[2]: <a href="http://twistedmatrix.com/documents/14.0.0/core/howto/components.html" rel="nofollow">http://twistedmatrix.com/documents/14.0.0/core/howto/compone...</a>
It would be very helpful to add to the README a section explaining what problems this solves. So examples of conventional python classes exhibiting weaknesses that are improved by using yuppy features.