Author mark.dickinson
Recipients belopolsky, jdwhitley, mark.dickinson
Date 2010-08-28.17:38:08
SpamBayes Score 6.47095e-10
Marked as misclassified No
Message-id <>
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".
Date User Action Args
2010-08-28 17:38:11mark.dickinsonsetrecipients: + mark.dickinson, belopolsky, jdwhitley
2010-08-28 17:38:11mark.dickinsonsetmessageid: <>
2010-08-28 17:38:09mark.dickinsonlinkissue9574 messages
2010-08-28 17:38:08mark.dickinsoncreate