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

[Raymond Hettinger]

[Terry Reedy]
>> 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 ;-).

[Nick Coghlan]
> 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)

I vote for complete removal of the bit flipping methods.

There's a cost to creating new ABCs that are devoid of use cases.
When Terry says "I am not sure of the purpose of the class ...", I think he 
meant that a binary abc wasn't proposed because of its questionable utility.

At some point, if you want an int type, you just use an int type.
What is the purpose of having yet another layer in the "numeric tower"?
Does anyone actually need an int lookalike with binary methods but
cannot just inherit from int?

Looking back at PEP 3119, I see there was an early decision
"between standardizing more, fine-grained ABCs or fewer, course-grained
ones" and that the choice was resolved in favor the few.  That is how we 
avoided urban sprawl with the likes of "ComposableSet, MutableSet, 
HashableSet, MutableComposableSet, HashableComposableSet".

I had thought everyone was on-board with the notion that thin abcs
that capture the essence of a type are better than fat abcs
that seek emulate every aspect of a single concrete type.
Without agreement on that premise, simplification is a lost cause.

If the group wants to go forward with a Binary subclass of Integral,
then I would like to withdraw this simplification mini-pep.  Better
to stick with what we have now than to addcomplexity to a module
that is already use case challenged.


Raymond