Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
I recommend switching back to __int__ and int; even in 2.5, these are expected to return either an int or a long as required. There's no need to mess with __long__ at all. On Fri, Jun 6, 2008 at 8:25 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > Well, it seems like Integral instances should be able to be passed to > either int() or long(), so __long__ should probably stay. I have no > idea why I didn't include __int__, but its absence was probably the > only reason __index__ calls long() instead of int(). > > On Fri, Jun 6, 2008 at 3:23 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> Both of these seem 2.6-specific quirks. Those lines wereJeffrey's; >> maybe he remembers? I'm guessing that adding __long__ was done since >> 2.6 supports it, and the removal of __int__ was an oversight. I also >> think that there's no reason to change __index__ to call long(); int() >> will automatically return a long as needed. Maybe changing __long__ >> back to __int__ is also harmless. >> >> On Fri, Jun 6, 2008 at 2:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>> From: "Guido van Rossum" <[EMAIL PROTECTED]> Make that int() instead of long() and I'm okay with it. >>> >>> Does anyone know why Integral says that __long__ is a required abstract >>> method, but not __int__? >>> >>> Likewise, why is index() defined as long(self) instead of int(self)? >>> >>> There may be some design nuance that I'm not seeing. >>> >>> >>> Raymond >>> ___ >>> 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/) >> > > > > -- > Namasté, > Jeffrey Yasskin > http://jeffrey.yasskin.info/ > -- --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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
Well, it seems like Integral instances should be able to be passed to either int() or long(), so __long__ should probably stay. I have no idea why I didn't include __int__, but its absence was probably the only reason __index__ calls long() instead of int(). On Fri, Jun 6, 2008 at 3:23 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Both of these seem 2.6-specific quirks. Those lines wereJeffrey's; > maybe he remembers? I'm guessing that adding __long__ was done since > 2.6 supports it, and the removal of __int__ was an oversight. I also > think that there's no reason to change __index__ to call long(); int() > will automatically return a long as needed. Maybe changing __long__ > back to __int__ is also harmless. > > On Fri, Jun 6, 2008 at 2:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> From: "Guido van Rossum" <[EMAIL PROTECTED]> >>> >>> Make that int() instead of long() and I'm okay with it. >> >> Does anyone know why Integral says that __long__ is a required abstract >> method, but not __int__? >> >> Likewise, why is index() defined as long(self) instead of int(self)? >> >> There may be some design nuance that I'm not seeing. >> >> >> Raymond >> ___ >> 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/) > -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
Both of these seem 2.6-specific quirks. Those lines wereJeffrey's; maybe he remembers? I'm guessing that adding __long__ was done since 2.6 supports it, and the removal of __int__ was an oversight. I also think that there's no reason to change __index__ to call long(); int() will automatically return a long as needed. Maybe changing __long__ back to __int__ is also harmless. On Fri, Jun 6, 2008 at 2:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > From: "Guido van Rossum" <[EMAIL PROTECTED]> >> >> Make that int() instead of long() and I'm okay with it. > > Does anyone know why Integral says that __long__ is a required abstract > method, but not __int__? > > Likewise, why is index() defined as long(self) instead of int(self)? > > There may be some design nuance that I'm not seeing. > > > Raymond > ___ > 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
From: "Guido van Rossum" <[EMAIL PROTECTED]> Make that int() instead of long() and I'm okay with it. Does anyone know why Integral says that __long__ is a required abstract method, but not __int__? Likewise, why is index() defined as long(self) instead of int(self)? There may be some design nuance that I'm not seeing. Raymond ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
Make that int() instead of long() and I'm okay with it. On Fri, Jun 6, 2008 at 1:33 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > New idea! I missed an obvious solution. Let the binary methods in Integral > be mixins instead of abstract methods. That minimizes the burden on the > class implementer while providing maximum support for clients. > > class Integral(Rational): > ... > def __lshift__(self, other): > """self << other""" > return long(self) << long(other) > def __xor__(self, other): > """self ^ other""" > return long(self) ^ long(other) > > I worried a bit about changing type, but this kind of thing is already baked > into numbers.py: > > @property > def imag(self): > """Real numbers have no imaginary component.""" > return 0 > > @property > def denominator(self): > """Integers have a denominator of 1.""" > return 1 > > Raymond > > > ----- Original Message - From: "Alex Martelli" <[EMAIL PROTECTED]> > To: "Guido van Rossum" <[EMAIL PROTECTED]> > Cc: "Raymond Hettinger" <[EMAIL PROTECTED]>; > Sent: Friday, June 06, 2008 11:40 AM > Subject: Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC > > >> On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <[EMAIL PROTECTED]> >> wrote: >>> >>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>>> >>>> Does anyone actually need an int lookalike with binary methods but >>>> cannot just inherit from int? >>> >>> Does anyone actually need an int lookalike with operations like +, - >>> etc. but cannot just inherit from int? If the answer is yes, is there >>> a compelling reason why they wouldn't want to support binary methods >>> as well? >> >> Yes, there's a use case for implementing long integers as arrays of >> decimal digits -- addition is roughly as efficient as for binary >> integers (x86 chips still have instructions to help with that), and >> emitting as decimal digits is MUCH more efficient of course -- so if >> I/O in decimal form is the most common operation, with a little >> arithmetic (particularly sums), you could gain performance; binary >> operations, however, would be as inefficient as decimal form >> conversion is for ordinary binary ints, and not needed for the typical >> applications that would use these "decimal coded integers" >> (accounting), so why not save the implementer of such an extension >> from having to write that unneeded and slow extra code? >> >> >> Alex > > -- --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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
New idea! I missed an obvious solution. Let the binary methods in Integral be mixins instead of abstract methods. That minimizes the burden on the class implementer while providing maximum support for clients. class Integral(Rational): ... def __lshift__(self, other): """self << other""" return long(self) << long(other) def __xor__(self, other): """self ^ other""" return long(self) ^ long(other) I worried a bit about changing type, but this kind of thing is already baked into numbers.py: @property def imag(self): """Real numbers have no imaginary component.""" return 0 @property def denominator(self): """Integers have a denominator of 1.""" return 1 Raymond - Original Message - From: "Alex Martelli" <[EMAIL PROTECTED]> To: "Guido van Rossum" <[EMAIL PROTECTED]> Cc: "Raymond Hettinger" <[EMAIL PROTECTED]>; Sent: Friday, June 06, 2008 11:40 AM Subject: Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these "decimal coded integers" (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? Alex ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
In data 06 giugno 2008 alle ore 20:40:01, Alex Martelli <[EMAIL PROTECTED]> ha scritto: > On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>> Does anyone actually need an int lookalike with binary methods but >>> cannot just inherit from int? >> >> Does anyone actually need an int lookalike with operations like +, - >> etc. but cannot just inherit from int? If the answer is yes, is there >> a compelling reason why they wouldn't want to support binary methods >> as well? > > Yes, there's a use case for implementing long integers as arrays of > decimal digits -- addition is roughly as efficient as for binary > integers (x86 chips still have instructions to help with that), and > emitting as decimal digits is MUCH more efficient of course -- so if > I/O in decimal form is the most common operation, with a little > arithmetic (particularly sums), you could gain performance; binary > operations, however, would be as inefficient as decimal form > conversion is for ordinary binary ints, and not needed for the typical > applications that would use these "decimal coded integers" > (accounting), so why not save the implementer of such an extension > from having to write that unneeded and slow extra code? > > > Alex I don't know if you are talking about BCD numbers, but they are quite inefficient and slow in x86 architecture. There are instructions only to add and subtract packed BCD numbers which uses just two decimal digits (packed in two nibbles into a single byte). For unpacked BCDs, there are instructions to add, subtract, multiply and divide numbers, but which uses only one digit at the time. So using packed BCDs to store 8 decimal digits in 32 bits, for example, requires 4 instructions to make addictions or subractions, plus the required shift & mask instructions to put every couple digits into the AL register to execute BCD operations. Unpacked BCDs need double of them. Also, these instructions still use microcode to execute on modern processors, slowing down the execution pipeline (most of the simpler instructions do not require microcode, and execute "directly"). Last but not least, on x86-64 architecture BCD instructions were completely removed from the ISA; opcodes are assigned to new instructions. Obviously, binary operations can be performed twice faster thanks to the 64 bit registers and ALUs. The only practical advantage on using BCD numbers is the conversion-to-string operation, which can be done faster than binary numbers. Binary addition, subtraction, multiplication and division are greatly faster than BCD ones, and should be the preferred way to do integer math. Cesare ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Fri, Jun 6, 2008 at 11:40 AM, Alex Martelli <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>> Does anyone actually need an int lookalike with binary methods but >>> cannot just inherit from int? >> >> Does anyone actually need an int lookalike with operations like +, - >> etc. but cannot just inherit from int? If the answer is yes, is there >> a compelling reason why they wouldn't want to support binary methods >> as well? > > Yes, there's a use case for implementing long integers as arrays of > decimal digits -- addition is roughly as efficient as for binary > integers (x86 chips still have instructions to help with that), and > emitting as decimal digits is MUCH more efficient of course -- so if > I/O in decimal form is the most common operation, with a little > arithmetic (particularly sums), you could gain performance; I tried this with ABC in '83. We didn't see any of the hoped-for benefits though. That's why Python has binary long integers. :-) > binary > operations, however, would be as inefficient as decimal form > conversion is for ordinary binary ints, and not needed for the typical > applications that would use these "decimal coded integers" > (accounting), so why not save the implementer of such an extension > from having to write that unneeded and slow extra code? You could just raise an exception. This is common in Java when an Interface requires you implement a method you can't. Or use virtual inheritance from the Integral class and leave them unimplemented. See if anyone cares. :-) -- --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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Does anyone actually need an int lookalike with binary methods but >> cannot just inherit from int? > > Does anyone actually need an int lookalike with operations like +, - > etc. but cannot just inherit from int? If the answer is yes, is there > a compelling reason why they wouldn't want to support binary methods > as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these "decimal coded integers" (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? Alex ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
2008/6/6 Guido van Rossum <[EMAIL PROTECTED]>: > On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Does anyone actually need an int lookalike with binary methods but >> cannot just inherit from int? > > Does anyone actually need an int lookalike with operations like +, - > etc. but cannot just inherit from int? If the answer is yes, is there > a compelling reason why they wouldn't want to support binary methods > as well? I have no vested interest either way, but I think someone mentioned creating a long int equivalent based on Decimal earlier in the thread. Wrappers for the gmp library might also want to do this. It's hardly the world's biggest use case, though... Paul. ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Does anyone actually need an int lookalike with binary methods but > cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? -- --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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
[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 ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Thu, Jun 05, 2008 at 09:41:44AM -0700, Bill Janssen wrote: > > I think I agree with Raymond on the basic principle that simple ABC's > > are easier to use than simple ones. > > I don't think he was saying that. He was saying that simple ABC's are > easier to implement to. Sorry; I used the wrong word. I should have said "implement to" rather than "use." I agree with you. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
> I think I agree with Raymond on the basic principle that simple ABC's > are easier to use than simple ones. I don't think he was saying that. He was saying that simple ABC's are easier to implement to. It's not at all clear to me that simple ABC's are good in and of themselves. I think a String ABC should probably include all the methods that basestring provides, perhaps by reducing the methods that basestring provides, and moving the removed methods to the String ABC, with implementations that call the methods provided by basestring. That way, String classes could be implemented by overriding the "base" set of methods, but still inherit from String to get the other methods. But, then, isn't basestring the true simple ABC for strings? Bill ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
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) 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__. 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. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
I think it's fine to remove 3-arg pow() from the ABC; implementations are of course free to provide it. Raymond, why don't you cook up a patch? It should patch both the PEP and numbers.py. On Wed, Jun 4, 2008 at 8:44 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > On Sun, Jun 1, 2008 at 2:15 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> >> 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. > > +1 from me. > I'd support removing all these, minus the exceptions already pointed out > (__index__, numerator, denominator). As a (so far incomplete) effort > to speed up the Decimal type I recently implemented a decimal-based > integer type; this type would seem a natural candidate to inherit > from Integral, but the logical and shift operators above make less sense > for this type. > The other odd man out here is three-argument pow; this *is* a > method that makes sense for integers without reference to the > way they're stored. So maybe this should stay. (Though I've > occasionally wondered why three-argument pow is part of the > core language, rather than being in the standard library.) > Mark > > ___ > 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Sun, Jun 1, 2008 at 2:15 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > 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. > +1 from me. I'd support removing all these, minus the exceptions already pointed out (__index__, numerator, denominator). As a (so far incomplete) effort to speed up the Decimal type I recently implemented a decimal-based integer type; this type would seem a natural candidate to inherit from Integral, but the logical and shift operators above make less sense for this type. The other odd man out here is three-argument pow; this *is* a method that makes sense for integers without reference to the way they're stored. So maybe this should stay. (Though I've occasionally wondered why three-argument pow is part of the core language, rather than being in the standard library.) Mark ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
"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 notice that the similarly implementation-based frexp and ldexp math methods are *not* in the Real class. | Requiring all those methods to be defined makes it harder to write | a compliant class. Other than int/long, no currently existing type | matches-up with Integral. Does anyone care about this? I might some day, for didactic purposes, write integer classes based on prime-factorization or fibonacci representations. I certainly would skip all the 2s-complement methods. But I do not know that I would care much about being 'non-compliant'. | If something like numpy's int8 eventually grows the required methods, | it is worriesome that the numerator/denominator properties will be | automatically supplied for fractions.py to accept as inputs eventhough | int8's wrap-around behavior makes them entirely unsuitable. In my view, the members of residue/remainder classes are not really integers unless their usage is carefully restricted to avoid invocation of the mod operation. Terry Jan Reedy ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Wed, Jun 4, 2008 at 12:57 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > 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". > Requiring all those methods to be defined makes it harder to write > a compliant class. > > Other than int/long, no currently existing type > matches-up with Integral. Does anyone care about this? > > Hopefully, some discussion gets generated. But if no one cares, I'll > happily drop it. I'm just responding out of duty to add more discussion on the topic. I think I agree with Raymond on the basic principle that simple ABC's are easier to use than simple ones. Anyway, it's hard to add anything to the discussion when I haven't seen many applications of the Integral ABC, but in principle, but if I had to vote I'd say that the bitwise operators aren't particularly integery. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Wed, Jun 4, 2008 at 12:57 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > 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". > Requiring all those methods to be defined makes it harder to write > a compliant class. In general it is good to require that more thought goes into the design and implementation of a class, so that less thought needs to go into using it. > Other than int/long, no currently existing type > matches-up with Integral. Does anyone care about this? Does "this" refer to "the Integral ABC" or "no type matches up with it" ? > If something like numpy's int8 eventually grows the required methods, > it is worrysome that the numerator/denominator properties will be > automatically supplied for fractions.py to accept as inputs eventhough > int8's wrap-around behavior makes them entirely unsuitable. I'm not sure what you mean. This is probably just my lack of imagination. Can you give a small code example where using an int8 with the fractions module would cause problems? The Fraction class appears to be calling __index__ on its arguments, which would convert the int8 to a proper int (or long, in Python 2.6). > I don't > know if this bothers anyone. It would seem that a consumer of an Integral > can assume the existence of methods but nothing about whether the > result is usable. That might not be a big deal except that numpy is t > he only known use case. Any integer type that performs arithmetic modulo some number is problematic. Perhaps a totally separate ABC needs to be defined for this purpose, one that doesn't inherit from Rational. > Hopefully, some discussion gets generated. But if no one cares, I'll > happily drop it. Have you asked the numpy folks? If enough people care, we could easily create a BinaryInteger ABC that defines the bitwise operations. -- --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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
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". Requiring all those methods to be defined makes it harder to write a compliant class. Other than int/long, no currently existing type matches-up with Integral. Does anyone care about this? If something like numpy's int8 eventually grows the required methods, it is worriesome that the numerator/denominator properties will be automatically supplied for fractions.py to accept as inputs eventhough int8's wrap-around behavior makes them entirely unsuitable. I don't know if this bothers anyone. It would seem that a consumer of an Integral can assume the existence of methods but nothing about whether the result is usable. That might not be a big deal except that numpy is t he only known use case. Hopefully, some discussion gets generated. But if no one cares, I'll happily drop it. Raymond ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
Because .numerator and .denominator are defined by the Rational ABC, and Integral inherits from that, removing them from Integral is a larger change than removing the other methods. You'd have to remove them from Rational or break the inheritance relation. Removing the bitwise operators sounds fine to me. 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/jyasskin%40gmail.com > -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
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/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Sat, May 31, 2008, Raymond Hettinger wrote: > > 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. The only thing I object to is removing __index__ -- the whole point of an integral class is that it is substitutable as an index for sequences in a way that other numeric types are not. Having an __index__ special method is a key indicator for duck-typing purposes not covered by the ABC. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Need a book? Use your library! ___ 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
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Sun, Jun 1, 2008 at 8:15 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > 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. Add: * Faster big integers (gmpy) * Integers with exact division to rationals (e.g. sympy) Fredrik ___ 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
