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

Ok.

> It made sense for floats because of prevalence of use cases and 
> because we wanted to match IEEE-754R as much as possible.

But why shouldn't this apply to complex numbers ? I am biased because I
mainly use python for scientific work, but complex numbers are not more
special than float in my mind.

> Unfortunately, the support for Infs and NaNs has already negatively 
> impacted the float world by making the math module harder to maintain
> and test.

Yes, it is difficult to handle nan and inf, there are a lot of corner
cases. But I fail to see how this applies here: my patch is essentially
a rewrote of the parsing, and the code to handle nan/inf is only 7
lines. This is independent of the handling of how nan/inf is handled by
math operations on it.

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

Hm, not sure what you mean here by standard interpretation, but
infinities "do not meet", in the sense that (x,inf) and (inf,x) for
example can never been 'near' from each other (in the distance sense),
except if x is inf. It does not make more sense to talk about phase of
complex numbers with inf than for 0. But again, I don't see how this is
relevant to the proposed feature. 

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

For any task where parsing complex makes sense. Since many numerical
operations may end up with nan or inf, this is relatively common I would
say.

It this can make the review easier, I can split the patch in two: first
the refactoring (+ tests once someone tells me how to), and then 
inf/nan handling (with additional tests).