[Python-Dev] Mini-Pep: Simplifying the Integral ABC (original) (raw)

Raymond Hettinger python at rcn.com
Fri Jun 6 05:45:27 CEST 2008

[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

More information about the Python-Dev mailing list