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

[Guido van Rossum]

On Thu, Jun 5, 2008 at 6:20 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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)

Agreed. Let's move these into a separate BinaryInteger class.

> 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__.

Let's ditch 3-arg pow, but keep __long__ (in 2.6) and __index__.
Actually __long__ can go too.

> 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.

I definitely want to keep these. They're essential for people who want
to use the higher-up classes in the numeric tower.

I think this is settled now; Raymond can update PEP 3141 (if he
refrains from editorializing) and patch numbers.py.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)