[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?
> Raymond
> ----- Original Message -----
>> Target:  Py2.6 and Py3.0
>> Author: Raymond Hettinger
>> Date: May 31, 2008
>> Motivation
>> ----------
>> 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
>> substitutions
>> are precluded because the ABC is too aggressive in its behavioral
>> requirements
>> -- mandating too many methods, mandating methods that are difficult to
>> implement, or too closely following the full API of a single concrete
>> type.
>> The Integral ABC is somewhat extensive and requires essentially every
>> behavior
>> exhibited by the int concrete class.  Usefully, it provides for basic
>> integer
>> behaviors like simple arithmetic and ordering relations.  However, the
>> current
>> ABC goes beyond that and requires bit-flipping and other operations that
>> are
>> not fundamental to the notion of being an integer.  That makes it
>> challenging
>> to define a new Integral class that isn't already an int.
>> Proposal
>> --------
>> Remove non-essential abstract methods like __index__, three argument
>> __pow__,
>> __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__,
>> __xor__,
>> __rxor__, __or__, __ror__, and __invert__, numerator, and denominator.
>> Discussion
>> ----------
>> 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
>> methods
>> present in Integral except for the new methods like __trunc__, __index__,
>> real, imag, conjugate, numerator, and denominator.  For the most part,
>> they
>> are fully substitutable into code that expects regular ints; however, they
>> do
>> 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
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/python%40rcn.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org

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

More information about the Python-Dev mailing list