[Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

[Jeffrey Yasskin]

On 4/28/07, Baptiste Carvello <baptiste13 at 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