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
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
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.
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
I think the behavior when supplying a custom mapping type to __dict__
is a little confusing. I'd like to supply a patch, but I'm not sure
what the preferred solution is.
Let me explain the problem a little first.
For a custom mapping type that does not inherit from dict, Python
gives a nice erro
Brett C. wrote:
I have decided that I am going to stop doing the python-dev Summaries
> after PyCon; the Summary covering the last half of March 2005 will be
> it for me.
I (as well as most, I'd guess) have enjoyed your voice in the summaries.
Thanks for a great series of summaries. Perhaps your f
> 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
