Nick Coghlan wrote:
Guido van Rossum wrote:
No, the reason is that if we did this with exceptions, it would be
liable to mask errors; an exception does not necessarily originate
immediately with the code you invoked, it could have been raised by
something else that was invoked by that code. The spe
Greg Ewing wrote:
Is there some reason why Context couldn't invoke the binary
operator methods using binary operators, rather than calling
their methods directly?
I had a similar idea, but then I remembered that the whole point of invoking the
methods through a specific Context is to override the
Michael Hudson wrote:
PS: this beahviour seems odd already:
decimal.getcontext().abs(1)
Traceback (most recent call last):
File "", line 1, in ?
File "/Users/mwh/Source/python/dist/src/Lib/decimal.py", line 2321, in abs
return a.__abs__(context=self)
TypeError: wrapper __abs__ doesn't take
Guido van Rossum wrote:
No, the reason is that if we did this with exceptions, it would be
liable to mask errors; an exception does not necessarily originate
immediately with the code you invoked, it could have been raised by
something else that was invoked by that code. The special value
NotImplem
> Nick Craig-Wood wrote:
> > Why is it like that?
Nick Coghlan replied:
> Speed, I assume - if it was exception based, then *every* operation
> effectively
> gets wrapped in a try/except block. Yikes!
No, the reason is that if we did this with exceptions, it would be
liable to mask errors; an ex
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Neil Schemenauer wrote:
>> IMO, Decimal should
>> be returning NotImplemented instead of raising TypeError.
>
> I agree, but I'm also interested in the fact that nobody commented on
> this before Python 2.4 went out. I read the reference page on numeric
Nick Craig-Wood wrote:
Why is it like that?
Speed, I assume - if it was exception based, then *every* operation effectively
gets wrapped in a try/except block. Yikes!
Also, for C implementations, the error return is fairly natural. It's only when
implementing operations in Python that it bites.
Neil Schemenauer wrote:
IMO, Decimal should
be returning NotImplemented instead of raising TypeError.
I agree, but I'm also interested in the fact that nobody commented on this
before Python 2.4 went out. I read the reference page on numeric coercion more
times than I care to count, and still di
On Tue, Mar 01, 2005 at 05:55:50PM -0500, Neil Schemenauer wrote:
> On Tue, Mar 01, 2005 at 11:45:43PM +1000, Nick Coghlan wrote:
> > Interesting. In that case, my other suggestion was to have raising
> > NotImplementedError from a special method be the equivalent of returning
> > NotImplemented
On Tue, Mar 01, 2005 at 11:45:43PM +1000, Nick Coghlan wrote:
> Interesting. In that case, my other suggestion was to have raising
> NotImplementedError from a special method be the equivalent of returning
> NotImplemented (which makes life much easier for a class like Decimal which
> has an int
Raymond Hettinger wrote:
Try to address this in a larger context than decimal. The same sort of
logic is present in sets.py and in datetime objects.
Interesting. In that case, my other suggestion was to have raising
NotImplementedError from a special method be the equivalent of returning
NotImpl
> A recent question on c.l.p pointed out that the 2.4 Decimal
implementation
> raises TypeError directly for operator arguments it doesn't
understand,
> instead
> of returning NotImplemented.
>
> Obviously, this creates problems for anyone trying to define a class
that
> 'plays
> nicely' with Deci
A recent question on c.l.p pointed out that the 2.4 Decimal implementation
raises TypeError directly for operator arguments it doesn't understand, instead
of returning NotImplemented.
Obviously, this creates problems for anyone trying to define a class that 'plays
nicely' with Decimal (but does
13 matches
Mail list logo
