Obviously, this creates problems for anyone trying to define a class that 'plays nicely' with Decimal (but does not inherit from Decimal), since their __rop__ methods never get called - Decimal's TypeError gets in the way.
I had another look at the PEP and didn't see anything on this topic, and I can't recall any discussion on the topic either on this list, or directly with Raymond and Facundo (Google doesn't have anything, either).
My current thoughts run as follows:
1. The standard binary operations (that is, '/', '*', '+', '-', '%', '**', '//', divmod(), cmp()) should be returning NotImplemented instead of raising TypeError directly.
2. The method-only operations should continue to raise TypeErrors
3. Invocations via Context methods should continue to raise TypeErrors
I was going to say this couldn't be fixed for Python 2.4 because it was a semantic change. But I modified my local copy to work this way, and the full Decimal test suite passed without any issue.
For syntax-based access, the bad call still results in a TypeError from the PyNumber_* machinery, and there isn't anything in the docs that says anything about whether a bad operand in a direct call to a special method results in NotImplemented being returned or TypeError being raised.
So, 2 questions:
1. Should Python 2.5's C implementation of Decimal follow the standard numeric coercion rules as described above?
2. Is it reasonable to class this as a bugfix and fix the Python version for 2.4.2? (2.4.1's a bit too soon for my liking)
Cheers, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
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
