Mathematically, â„‚ (complex) is a superset of â„ (real), and Decimals are a
kind of real(ish) number, like float:
The Python complex type represents a subset of â„‚. The Python Decimal
and float types implement a subset of â„, which as you say is a subset
of â„‚. The Python int type implements a subset of â„¤. (Although if you
have infinite storage, you could theoretically represent all of â„¤ with
int, and possibly all of â„ with Decimal. But I don't know of any
Python implementation that can utilize infinite RAM.)
The question isn't really about the mathematical number sets, but
about what operations you can do. The numbers.Complex type specifies
(3.4.0):
class Complex(Number)
 Complex defines the operations that work on the builtin complex type.

 In short, those are: a conversion to complex, .real, .imag, +, ,
 *, /, abs(), .conjugate, ==, and !=.
From what I can see, all of those operations are defined for Decimal,
*as long as you work exclusively with Decimal*. You can check their
..real and .imag (.imag will be Decimal('0'), and .real is self), you
can conjugate them (returns self), and you can do arithmetic with
them. But you can't mix complex and decimal, any more than you can mix
float and decimal:
Traceback (most recent call last):
File "<pyshell#30>", line 1, in <module>
Decimal('2')+3.0
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float'Traceback (most recent call last):
File "<pyshell#31>", line 1, in <module>
Decimal('2')+complex(3.0)
TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'complex'
Ergo, currently, you can't say that decimal.Decimal can be treated as
a complex. (Although you can call complex(d) and get back a meaningful
value, within the limits of precision  again, same as with float(d).)
To contrast, numbers.Number places very few requirements on its
subclasses. And decimal.Decimal isn't a subclass of any of the rest of
the tower:
print(cls,"",isinstance(d,getattr(numbers,cls)))
Number  True
Complex  False
Real  False
Rational  False
Integral  False
As I understand it, isinstance(x,numbers.Complex) should be True for
anything that you can treat like a complex()  that is, that you can
add it to a complex(), do operations on it, etc, etc, etc. I'm not
sure what isinstance(x,numbers.Number) promises in terms of usability;
I guess if you have a list of Numbers that are all the same type, you
can probably sum them, but you can sum nonNumbers too. The docstring
is a bit vague  sure, it's a number, but what can you do with it?
ChrisA