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. --Guido On Wed, Jun 4, 2008 at 1:54 AM, Raymond Hettinger <[EMAIL PROTECTED]> 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@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@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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
