numbers — Numeric abstract base classes

Source code:Lib/numbers.py

Thenumbers module (PEP 3141) defines a hierarchy of numericabstract base classes which progressively definemore operations. None of the types defined in this module are intended to be instantiated.

classnumbers.Number

The root of the numeric hierarchy. If you just want to check if an argumentx is a number, without caring what kind, useisinstance(x,Number).

The numeric tower

classnumbers.Complex

Subclasses of this type describe complex numbers and include the operationsthat work on the built-incomplex type. These are: conversions tocomplex andbool,real,imag,+,-,*,/,**,abs(),conjugate(),==, and!=. All except- and!= are abstract.

real

Abstract. Retrieves the real component of this number.

imag

Abstract. Retrieves the imaginary component of this number.

abstractmethodconjugate()

Abstract. Returns the complex conjugate. For example,(1+3j).conjugate()==(1-3j).

classnumbers.Real

ToComplex,Real adds the operations that work on realnumbers.

In short, those are: a conversion tofloat,math.trunc(),round(),math.floor(),math.ceil(),divmod(),//,%,<,<=,>, and>=.

Real also provides defaults forcomplex(),real,imag, andconjugate().

classnumbers.Rational

SubtypesReal and addsnumerator anddenominator properties. It also provides a default forfloat().

Thenumerator anddenominator valuesshould be instances ofIntegral and should be in lowest terms withdenominator positive.

numerator

Abstract. The numerator of this rational number.

denominator

Abstract. The denominator of this rational number.

classnumbers.Integral

SubtypesRational and adds a conversion toint. Providesdefaults forfloat(),numerator, anddenominator. Adds abstract methods forpow() withmodulus and bit-string operations:<<,>>,&,^,|,~.

Notes for type implementers

Implementers should be careful to make equal numbers equal and hashthem to the same values. This may be subtle if there are two differentextensions of the real numbers. For example,fractions.Fractionimplementshash() as follows:

def__hash__(self):ifself.denominator==1:# Get integers right.returnhash(self.numerator)# Expensive check, but definitely correct.ifself==float(self):returnhash(float(self))else:# Use tuple's hash to avoid a high collision rate on# simple fractions.returnhash((self.numerator,self.denominator))

Adding More Numeric ABCs

There are, of course, more possible ABCs for numbers, and this wouldbe a poor hierarchy if it precluded the possibility of addingthose. You can addMyFoo betweenComplex andReal with:

classMyFoo(Complex):...MyFoo.register(Real)

Implementing the arithmetic operations

We want to implement the arithmetic operations so that mixed-modeoperations either call an implementation whose author knew about thetypes of both arguments, or convert both to the nearest built in typeand do the operation there. For subtypes ofIntegral, thismeans that__add__() and__radd__() should bedefined as:

classMyIntegral(Integral):def__add__(self,other):ifisinstance(other,MyIntegral):returndo_my_adding_stuff(self,other)elifisinstance(other,OtherTypeIKnowAbout):returndo_my_other_adding_stuff(self,other)else:returnNotImplementeddef__radd__(self,other):ifisinstance(other,MyIntegral):returndo_my_adding_stuff(other,self)elifisinstance(other,OtherTypeIKnowAbout):returndo_my_other_adding_stuff(other,self)elifisinstance(other,Integral):returnint(other)+int(self)elifisinstance(other,Real):returnfloat(other)+float(self)elifisinstance(other,Complex):returncomplex(other)+complex(self)else:returnNotImplemented

There are 5 different cases for a mixed-type operation on subclassesofComplex. I’ll refer to all of the above code that doesn’trefer toMyIntegral andOtherTypeIKnowAbout as“boilerplate”.a will be an instance ofA, which is a subtypeofComplex (a:A<:Complex), andb:B<:Complex. I’ll considera+b:

  1. IfA defines an__add__() which acceptsb, all iswell.

  2. IfA falls back to the boilerplate code, and it were toreturn a value from__add__(), we’d miss the possibilitythatB defines a more intelligent__radd__(), so theboilerplate should returnNotImplemented from__add__(). (OrA may not implement__add__() atall.)

  3. ThenB’s__radd__() gets a chance. If it acceptsa, all is well.

  4. If it falls back to the boilerplate, there are no more possiblemethods to try, so this is where the default implementationshould live.

  5. IfB<:A, Python triesB.__radd__ beforeA.__add__. This is ok, because it was implemented withknowledge ofA, so it can handle those instances beforedelegating toComplex.

IfA<:Complex andB<:Real without sharing any other knowledge,then the appropriate shared operation is the one involving the builtincomplex, and both__radd__() s land there, soa+b==b+a.

Because most of the operations on any given type will be very similar,it can be useful to define a helper function which generates theforward and reverse instances of any given operator. For example,fractions.Fraction uses:

def_operator_fallbacks(monomorphic_operator,fallback_operator):defforward(a,b):ifisinstance(b,(int,Fraction)):returnmonomorphic_operator(a,b)elifisinstance(b,float):returnfallback_operator(float(a),b)elifisinstance(b,complex):returnfallback_operator(complex(a),b)else:returnNotImplementedforward.__name__='__'+fallback_operator.__name__+'__'forward.__doc__=monomorphic_operator.__doc__defreverse(b,a):ifisinstance(a,Rational):# Includes ints.returnmonomorphic_operator(a,b)elifisinstance(a,Real):returnfallback_operator(float(a),float(b))elifisinstance(a,Complex):returnfallback_operator(complex(a),complex(b))else:returnNotImplementedreverse.__name__='__r'+fallback_operator.__name__+'__'reverse.__doc__=monomorphic_operator.__doc__returnforward,reversedef_add(a,b):"""a + b"""returnFraction(a.numerator*b.denominator+b.numerator*a.denominator,a.denominator*b.denominator)__add__,__radd__=_operator_fallbacks(_add,operator.add)# ...