Mark Dickinson <[email protected]> added the comment:
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".
----------
assignee: mark.dickinson ->
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue9574>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
