Unassigning myself from this one, though I'll review a patch if anyone wants to write one.

After thinking about it a bit, I'm -0 on allowing the extra whitespace.  The main issue for me is that it opens up a can of worms about what should and shouldn't be allowed.  Which of the following should be allowed:

(a) complex("0.1 + 3j")
(b) complex("+ 3j")
(c) complex("+ 3")
(d) float("- 3")
(e) int("+ 3")
(f) complex("+4.0 + -5.0j")

Any patch would presumably allow (a).  (b) looks like it *should* be allowed, too, but then by analogy so does (c).  But for consistency, (d) and (e) would then have to be allowed, and I *really* don't want to go that far;  in particular, there are rules about what's allowed as a floating-point string that are fairly consistently applied throughout Python (e.g., in the float, Decimal and Fraction constructors);  these rules also agree with accepted standards (e.g., C99, IEEE 754), which clearly don't allow a space between the optional sign and the body of the float.

So unless anyone particularly wants to pursue this, I'd suggest closing as "won't fix".