Well, if we distinguish between inheritance (meaning the adoption of code, its interfaces and potentially attributes or members from a parent abstraction) and conformance (meaning the adoption of an interface from an abstraction), it seems to me that the latter isn't enough to give you mix-ins. So in Java you traditionally couldn't mix functionality into a class from more than one superclass, but you could declare conformance to a number of interfaces, but that would still leave you with filling in the missing functionality in a concise fashion. Mixing typically implies the involvement of more than one thing, and single inheritance doesn't really provide much scope for that. I suppose that these traits allow the inclusion of code originating from outside any defined conformance hierarchy, which reminds me somewhat of aspect-oriented programming, if I recall the nature of that correctly.
I've used mix-ins in Python where multiple inheritance is possible (according to the above definitions), but where you want to avoid method resolution uncertainty or general untidiness, although I'd argue that architectures based on mix-ins can be quite stifling and that other mechanisms exist in Python that are preferable (mostly due to Python's dynamic typing and objects-as-callables support).