Tim Peters wrote:
[Tim]
unicodedata.numeric(u"\N{PLANCK CONSTANT OVER TWO PI}") Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: not a numeric character unicodedata.numeric(u"\N{EULER CONSTANT}") Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: not a numeric character unicodedata.numeric(u"\N{AIRSPEED OF AFRICAN SWALLOW}") UnicodeError: Unicode-Escape decoding error: Invalid Unicode Character Name
[MAL]
Perhaps you should submit these for Unicode 4.0 ;-)
Note that the first two are already there; they just don't have an associated numerical value. The last one was a hint that I was trying to write a frivolous msg while giving my "<wink>" key a break <wink>.
That's what I meant: you should submit the numeric values for the first two and opt for addition of the last.
But really, I don't suspect that anyone is going to do serious character to number conversion on these esoteric characters. Plain old digits will do just as they always have ...
Which is why I have to wonder whether there's *any* value in exposing the numeric-value property beyond regular old digits.
It is needed for Unicode 3.0 standard compliance and for whoever wants to use this data. Since the Unicode database explicitly contains fractions, I think adding the .rational() API would make sense to provide a different access method to this data. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/