I am happy to collaborate in finding a solution, but I do not have 
enough knowledge or skill to work with the code alone.

Simply documenting it does not remove the frustration that a few people 
will enounter. The key point being that you can subclass the other 
numeric types, but not complex. Worse, you may think that you have 
succeeded in subclassing complex too, because it is only when the 
__ropn__ binary operators are used that the type reverts to the base 
class type.

Would you want to subclass a numeric type? I agree, it is a bit obsure, 
but I did a search on this before making the post and there have been 
others who found the problem too. 

In my case, I think that the motivation may seem a bit obscure. I had 
developed some numerical-like types (from scratch -- no subclassing) 
and I wanted to be able to write functions taking as possible arguments 
these types and Python numerical types indifferently. I realised that I 
could not achieve exactly what I wanted, however, by subclassing float, 
int, etc I could add a few methods that would allow my generic 
functions to work with either my types or the subclassed Python types. 
At the same time, the subclassed numerical types could still be used as 
numerical quantities (float, int,...). It seemed like a pretty elegant 
solution.

If that explanation does not make sense, then I suppose other simpler 
motivations could be, eg, to subclass float so that only positive 
values are acceptable; to subclass complex so that only values lying 
within the unit circle are acceptable, etc. That is, one might like to 
define a type that can only take on physically meaningful values (mass 
cannot be negative, a complex reflection coeffcieint cannot have a 
magnitude greater than unity, ..)

So, my feeling is that this is worth fixing because the work done on 
float, int etc, is clearly useful and it appears (to me) that the 
complex case is an oversight.