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
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 v
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 ret
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
;"Real numbers have no imaginary component."""
> return 0
>
> @property
> def denominator(self):
> """Integers have a denominator of 1."""
> return 1
>
> Raymond
>
>
> ----- Original Message - From: &
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
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 wit
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
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 loo
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 +,
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 answe
[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 inc
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 wr
> 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 Stri
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
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
| >
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,
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 __
"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; striki
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".
> Requ
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 t
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 generat
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: .nume
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 fin
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 multi
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 denomi
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 div
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 s
28 matches
Mail list logo
