On 4/28/07, Baptiste Carvello <baptiste13@altern.org> wrote:
2) In the PEP, the concepts are used *inconsistently*. Complex derives from Ring because the set of complex numbers *is a* ring. Int derives from Complex because integer are complex numbers (or, alternatively, the set of integers *is included in* the set of complex numbers). The consistent way could be to make the Complex class an instance of Ring, not a subclass.
Good point. In this structure, isinstance(3, Ring) really means that 3 is a member of some (unspecified) ring, not that 3 isa Ring, but the ambiguity there is probably the root cause of the problem with mixed-mode operations. We should also say that isinstance(3, Complex) means that 3 is a member of some subring of the complex numbers, which preserves the claim that Complex is a subtype of Ring. Up to here, things make sense, but because of how ABCs work, we need issubclass(rational, Complex). I suppose that's true too, since isinstance(3.4, rational) means "3.4 is a member of the rational subring of the complex numbers", which implies that "3.4 is a member of some subring of the complex numbers." There may be better names for these concepts. Perhaps suffixing every numeric ABC with "Element"? Do you have suggestions? Jason Orendorff points out that Haskell typeclasses capture the fact that complex is an instance of Ring. I think imitating them as much as possible would indeed imply making the numeric ABCs into metaclasses (in Haskell terminology, "kinds"). To tell if the arguments to a function were in the same total order, you'd check if they had any common superclasses that were themselves instances of TotallyOrdered. I don't know enough about how metaclasses are typically used to know how that would conflict. -- Namasté, Jeffrey Yasskin