This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | amaury.forgeotdarc |
|---|---|
| Recipients | amaury.forgeotdarc, theller |
| Date | 2007年08月29日.17:06:02 |
| SpamBayes Score | 0.30896056 |
| Marked as misclassified | No |
| Message-id | <1188407163.35.0.0194631076846.issue1040@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I have a patch for this, which uses MBCS conversion instead of relying on the default utf-8 (here and several other places). Tested on a French version of winXP. Which leads me to the question: should Windows use MBCS encoding by default when converting between char* and PyUnicode, and not utf-8? There are some other tracker items which would benefit from this. After all, C strings can only come from 1) python code, 2) system i/o and messages, and 3) constants in source code. IMO, 1) can use the representation it prefers, 2) would clearly lead to less error if handled as MBCS and 3) only uses 7bit ascii. There is very little need for utf-8 here. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2007年08月29日 17:06:03 | amaury.forgeotdarc | set | spambayes_score: 0.308961 -> 0.30896056 recipients: + amaury.forgeotdarc, theller |
| 2007年08月29日 17:06:03 | amaury.forgeotdarc | set | spambayes_score: 0.308961 -> 0.308961 messageid: <1188407163.35.0.0194631076846.issue1040@psf.upfronthosting.co.za> |
| 2007年08月29日 17:06:03 | amaury.forgeotdarc | link | issue1040 messages |
| 2007年08月29日 17:06:02 | amaury.forgeotdarc | create | |