[Python-Dev] Python and the Unicode Character Database
steve at pearwood.info
Thu Dec 2 22:30:38 CET 2010
Martin v. Löwis wrote:
>>> Then these users should speak up and indicate their need, or somebody
>>> should speak up and confirm that there are users who actually want
>>> '١٢٣٤.٥٦' to denote 1234.56. To my knowledge, there is no writing
>>> system in which '١٢٣٤.٥٦e4' means 12345600.0.
>> I'm not sure what you're after here.
> That the current float() constructor accepts tons of bogus character
> strings and accepts them as numbers, and that it should stop doing so.
What bogus characters do the float() and int() constructors accept? As
far as I can see, they only accepts numerals.
> Notice that Python does *not* currently support printing numbers in
> other scripts - even though this may actually be more useful than
Lack of one function, even if more useful, does not imply that an
existing function should be removed.
> In the case of number parsing, I think Python would be better if
> float() rejected non-ASCII strings, and any support for such parsing
> should be redone correctly in a different place (preferably along with
> printing of numbers).
So your problems with the current behaviour are:
(1) in some unspecified way, it's not done correctly;
(2) it belongs somewhere other than float() and int().
That second is awfully close to bike-shedding. Since you accept that
Python *should* have the current behaviour, and Python *already* has the
current behaviour, it seems strange that you are kicking up such a fuss
merely to *move* the implementation of that behaviour out of the numeric
constructors into some unspecified "different place".
I think it would be constructive to explain:
- how the current behaviour is incorrect;
- your suggestions for correcting it; and
- a concrete suggestion for where you would like to see the behaviour
moved to, and why that would be better than where it currently is.
More information about the Python-Dev