Message123584
| Author | belopolsky |
|---|---|
| Recipients | belopolsky, eric.smith, ezio.melotti, ggenellina, lemburg, loewis, mark.dickinson, pitrou, rhettinger, terry.reedy |
| Date | 2010-12-07.22:39:53 |
| SpamBayes Score | 2.9420808e-06 |
| Marked as misclassified | No |
| Message-id | <1291761596.57.0.680976760189.issue6632@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I wish I discovered this issue when I was working on #10557! Chances are I wouldn't have started a long python-dev thread rehashing the same issues as I see discussed here. In any case, in #10557, I replaced core uses of PyUnicode_EncodeDecimal() with PyUnicode_TransformDecimalToASCII() which transforms unicode to unicode. There should not be any change in what digits builtin number types accept, but the C-API "codec" is defined to pass through anything that is not "Nd" while replacing Nd characters with the corresponding 0-9 digit. String to string codecs including hex have been readded in r86934. See issue 7475. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2010-12-07 22:39:56 | belopolsky | set | recipients: + belopolsky, lemburg, loewis, rhettinger, terry.reedy, mark.dickinson, ggenellina, pitrou, eric.smith, ezio.melotti |
| 2010-12-07 22:39:56 | belopolsky | set | messageid: <1291761596.57.0.680976760189.issue6632@psf.upfronthosting.co.za> |
| 2010-12-07 22:39:53 | belopolsky | link | issue6632 messages |
| 2010-12-07 22:39:53 | belopolsky | create | |