> complex(repr(..)) roundtrip should work,

Nice-to-have but not a requirement that the entire input domain be
supported. 

> it is supported for float, so why not for complex ?

It made sense for floats because of prevalence of use cases and because
we wanted to match IEEE-754R as much as possible.  Unfortunately, the
support for Infs and NaNs has already negatively impacted the float
world by making the math module harder to maintain and test.  I would
not like to see that extended to cmath or complex() unless compelling
real-world use cases arise.

> ... for scientific people, it is a crucial to have proper support
> of nan (which may mean missing data depending on the context) and inf.

Mark, does Inf have a standard interpretation for complex numbers?  Do
all infinities meet or do they radiate, each with their own phase angle?

Also, do you want to stick with the 754 interpretation of NaNs as the
result of invalid operations or are you comfortable with the
MatLab/Octave notion of using NaNs to indicate missing values (something
they do as an optimization because it is the only way to flag a
non-numeric value in a floating point register or C double)?

> it does not add complexity: 

That depends on whether handling of NaNs and Infs creeps into cmath.  

Mainly, I'm just questioning whether there exist compelling use cases
for parsing NaNs and Infs in the context of complex numbers.