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 <1283017091.41.0.0872431954949.issue9574@psf.upfronthosting.co.za>
In-reply-to
Content
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".
History
Date User Action Args
2010-08-28 17:38:11mark.dickinsonsetrecipients: + mark.dickinson, belopolsky, jdwhitley
2010-08-28 17:38:11mark.dickinsonsetmessageid: <1283017091.41.0.0872431954949.issue9574@psf.upfronthosting.co.za>
2010-08-28 17:38:09mark.dickinsonlinkissue9574 messages
2010-08-28 17:38:08mark.dickinsoncreate