On Thu, Jun 5, 2008 at 6:20 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Terry Reedy wrote: >> >> "Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> | From: "Guido van Rossum" <[EMAIL PROTECTED]> >> | > 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. >> | >> | Not sure how to generate more discussion. It seems self-evident >> | that an abc with lots of abstract methods is inherently less usable >> | and that bitwise operations go beyond the basic notion of >> "integeriness". >> >> 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 ;-). > > 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)
Agreed. Let's move these into a separate BinaryInteger class. > Note that this leaves the Integral ABC adding only __long__, __index__ and > 3-argument __pow__ over and above the Rational ABC. If 3-argument __pow__ > goes (which appears likely), we're left with __long__ and __index__. Let's ditch 3-arg pow, but keep __long__ (in 2.6) and __index__. Actually __long__ can go too. > However, there's still a few additional public properties and methods > inherited from higher up in the numeric stack which most existing integral > types are unlikely to provide: .real, .imag, .conjugate(). Unlike the > methods being relocated, however, these are absolutely trivial for all > non-complex numeric types. I definitely want to keep these. They're essential for people who want to use the higher-up classes in the numeric tower. I think this is settled now; Raymond can update PEP 3141 (if he refrains from editorializing) and patch numbers.py. -- --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
