[Python-Dev] Python and the Unicode Character Database (original) (raw)

Steven D'Aprano 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 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:

-- Steven

More information about the Python-Dev mailing list