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 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:48loewissetrecipients: + loewis, lemburg, doerwalter, georg.brandl, rhettinger, amaury.forgeotdarc, belopolsky, Rhamphoryncus, pitrou, vstinner, eric.smith, stutzbach, ezio.melotti
2010-12-30 07:57:45loewislinkissue10542 messages
2010-12-30 07:57:45loewiscreate