On Sun, Jun 15, 2014 at 11:28 AM, Roy Smith <r...@panix.com> wrote:
> In article <539dbcbe$0$29988$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
>
>> On Sun, 15 Jun 2014 01:22:50 -0600, Ian Kelly wrote:
>>
>> > On Sat, Jun 14, 2014 at 8:51 PM, Steven D'Aprano
>> > <steve+comp.lang.pyt...@pearwood.info> wrote:
>> >> Does anyone know any examples of values or types from the standard
>> >> library or well-known third-party libraries which satisfies
>> >> isinstance(a, numbers.Number) but not isinstance(a, numbers.Complex)?
>> >
>> >>>> issubclass(decimal.Decimal, numbers.Number)
>> > True
>> >>>> issubclass(decimal.Decimal, numbers.Complex)
>> > False
>>
>> Well, that surprises and disappoints me, but thank you for the answer.
>
> Why would you expect Decimal to be a subclass of Complex?
One might expect it for the same reason that float is a subclass of
Complex. Decimal was intentionally excluded from the numeric tower
(as noted in PEP 3141), but apparently it still subclasses Number. As
I understand it the reason Decimal was excluded was because it doesn't
fully implement the methods of Complex; for example, given two Complex
instances, one expects to be able to add them, but that doesn't always
hold for Decimal depending on the type of the other operand:
>>> Decimal("2.0") + 2.0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'
The Number ast doesn't specify any particular behavior and is there to
"to make it easy for people to be fuzzy about what kind of number they
expect", so I guess the developers so no harm in letting Decimal
subclass it.
--
https://mail.python.org/mailman/listinfo/python-list
