[Python-Dev] Mini-Pep: Simplifying the Integral ABC
Guido van Rossum
guido at python.org
Wed Jun 4 17:33:48 CEST 2008
I haven't seen anyone applaud either.
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.
Jeffrey made a good point: .numerator and .denominator need to be kept
in the interface. I really don't want to divorce Integer from
Rational. They're trivial to implement, and I won't complain if you
leave them unimplemented while claiming conformance. :-)
My position: I'm -1 on removing __index__, numerator, denominator, and
on removing anything you didn't mention explicitly. You used the
phrase "methods like", which seems inappropriate for a specification.
Note also that these happen to be concrete methods, not abstract ones
like you claim.
I'm -0 on removing the bitwise operators, i.e. could be swayed by some +1 votes.
On Wed, Jun 4, 2008 at 1:54 AM, Raymond Hettinger <python at rcn.com> wrote:
> The only comment so far was to keep the __index__ method.
> Other than that, is this good to go?
> ----- Original Message -----
>> Target: Py2.6 and Py3.0
>> Author: Raymond Hettinger
>> Date: May 31, 2008
>> The principal purpose of an abstract base class is to support multiple
>> implementations of an API; thereby allowing one concrete class to be
>> substitutable for another. This purpose is defeated when useful
>> are precluded because the ABC is too aggressive in its behavioral
>> -- mandating too many methods, mandating methods that are difficult to
>> implement, or too closely following the full API of a single concrete
>> The Integral ABC is somewhat extensive and requires essentially every
>> exhibited by the int concrete class. Usefully, it provides for basic
>> behaviors like simple arithmetic and ordering relations. However, the
>> ABC goes beyond that and requires bit-flipping and other operations that
>> not fundamental to the notion of being an integer. That makes it
>> to define a new Integral class that isn't already an int.
>> Remove non-essential abstract methods like __index__, three argument
>> __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__,
>> __rxor__, __or__, __ror__, and __invert__, numerator, and denominator.
>> The only known use cases for variants of int are types that limit the
>> range of
>> values to those that fit in a fixed storage width.
>> One existing implementation is in numpy which has types like int0, int8,
>> int16, int32, and int16. The numpy integral types implement all the
>> present in Integral except for the new methods like __trunc__, __index__,
>> real, imag, conjugate, numerator, and denominator. For the most part,
>> are fully substitutable into code that expects regular ints; however, they
>> have wrap-around behaviors such as int8(200)+int8(100) --> int8(44). The
>> wrap-around behaviors make the numpy types totally unsuitable for some
>> applications of Integral such as the fractions module which accepts any
>> integral numerator and denominator.
>> Python-Dev mailing list
>> Python-Dev at python.org
> Python-Dev mailing list
> Python-Dev at python.org
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev