Message93056
| Author |
loewis |
| Recipients |
eric.smith, ezio.melotti, ggenellina, lemburg, loewis, mark.dickinson, pitrou |
| Date |
2009年09月24日.07:30:13 |
| SpamBayes Score |
2.8383845e-10 |
| Marked as misclassified |
No |
| Message-id |
<4ABA5541.6090207@v.loewis.de> |
| In-reply-to |
<4AB90123.7050500@egenix.com> |
| Content |
> The codec currently doesn't look at the base at all - and shouldn't
> need to:
>
> It simply converts input characters that have a decimal digit value
> associated with them, to the usual ASCII digits in preparation
> for parsing them using the standard number parsing tools we have in
> Python.
Right. And as such, it shouldn't stop with digit 9, but continue into
digits a, b, c, and so on, as appropriate.
> This is to support number representations using non-ASCII code
> points for digits (e.g. Japanese or Sanskrit numbers)
Notice that it also supports bases other than 10:
80
So calling it "decimal" is a misnomer.
> Also note that we already have a hex codec in Python 2.x
> which converts between the hex representations of a string
> and its regular form. This was removed in 3.x for some reason
> I don't understand (probably just an oversight).
The hex codec doesn't have to do anything with number conversions;
nor does it have to do with character encodings. To introduce it was
a mistake in Python 2.x which has been fixed in 3.x (by removing
it and other similar "codecs", such as rot13). |
|