[Python-Dev] Python and the Unicode Character Database

[Steven D'Aprano]

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
> parsing.

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.



-- 
Steven