[Python-Dev] Mini-Pep: Simplifying the Integral ABC
python at rcn.com
Fri Jun 6 22:33:05 CEST 2008
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.
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:
"""Real numbers have no imaginary component."""
"""Integers have a denominator of 1."""
----- Original Message -----
From: "Alex Martelli" <aleaxit at gmail.com>
To: "Guido van Rossum" <guido at python.org>
Cc: "Raymond Hettinger" <python at rcn.com>; <python-dev at python.org>
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 <guido at python.org> wrote:
>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <python at rcn.com> 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?
More information about the Python-Dev