Message124910
| Author |
loewis |
| Recipients |
Rhamphoryncus, amaury.forgeotdarc, belopolsky, doerwalter, eric.smith, ezio.melotti, georg.brandl, lemburg, loewis, pitrou, rhettinger, stutzbach, vstinner |
| Date |
2010年12月30日.07:57:45 |
| SpamBayes Score |
1.4405144e-13 |
| Marked as misclassified |
No |
| Message-id |
<4D1C3B78.8070809@v.loewis.de> |
| In-reply-to |
<AANLkTi=52uek6ByQSZ9E3aChYiQ15TukrDLKw9Mrcec3@mail.gmail.com> |
| Content |
> Are you serious? This sounds like a py4k idea. Can you give us a
> hint on what the new representation will be?
I'm thinking about an approach of a variable representation:
one, two, or four bytes, depending on the widest character that
appears in the string. I think it can be arranged to make this mostly
backwards-compatible with existing APIs, so it doesn't need to wait
for py4k, IMO. OTOH, I'm not sure I'll make it for 3.3.
> Meanwhile, what it your
> recommendation for application developers? Should they attempt to fix
> the code that assumes len(chr(i)) == 1? Should text processing
> applications designed to run on a narrow build simply reject non-BMP
> text? Should application writers avoid using str.isxyz() methods?
Given that this is vaporware: proceed as if that idea didn't exist. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2010年12月30日 07:57:48 | loewis | set | recipients:
+ loewis, lemburg, doerwalter, georg.brandl, rhettinger, amaury.forgeotdarc, belopolsky, Rhamphoryncus, pitrou, vstinner, eric.smith, stutzbach, ezio.melotti |
| 2010年12月30日 07:57:45 | loewis | link | issue10542 messages |
| 2010年12月30日 07:57:45 | loewis | create |
|