[Python-Dev] Mini-Pep: Simplifying the Integral ABC

Nick Coghlan ncoghlan at gmail.com
Thu Jun 5 15:20:40 CEST 2008

Terry Reedy wrote:
> "Raymond Hettinger" <python at rcn.com> wrote in message 
> news:2745D7EB7C064B16A88E433588021756 at RaymondLaptop1...
> | From: "Guido van Rossum" <guido at python.org>
> | > Unless more folks actually say they agree I don't want to go forward
> | > with this. There was quite a bit of discussion about PEP 3141 and it
> | > was accepted; striking this much from it with virtually no discussion
> | > seems wrong to me.
> |
> | Not sure how to generate more discussion.  It seems self-evident
> | that an abc with lots of abstract methods is inherently less usable
> | and that bitwise operations go beyond the basic notion of "integeriness".
> On reading PEP3141 some months ago and again today, I thought and still do 
> that all the methods that depend on a 2s-complement representation and 
> implementation really belong to an implentation-defined subclass of 
> Integral.  But I am not sure of the purpose of the class and of including 
> such concrete methods in an ABC, and so said nothing ;-).

I think it definitely makes sense to separate out the 
number-as-sequence-of-bits operations from the main Integral ABC. This 
would involve moving:

lshift, rshift, and, or, xor, invert (along with their reversed and 
in-place counterparts)

Note that this leaves the Integral ABC adding only __long__, __index__ 
and 3-argument __pow__ over and above the Rational ABC. If 3-argument 
__pow__ goes (which appears likely), we're left with __long__ and __index__.

However, there's still a few additional public properties and methods 
inherited from higher up in the numeric stack which most existing 
integral types are unlikely to provide: .real, .imag, .conjugate(). 
Unlike the methods being relocated, however, these are absolutely 
trivial for all non-complex numeric types.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list