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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4