[Python-Dev] PEP 393 Summer of Code Project

[Glenn Linderman]

On 8/24/2011 1:18 AM, "Martin v. Löwis" wrote:
>> So am I correctly reading between the lines when, after reading this
>> thread so far, and the complete issue discussion so far, that I see a
>> PEP 393 revision or replacement that has the following characteristics:
>>
>> 1) Narrow builds are dropped.
> PEP 393 already drops narrow builds.

I'd forgotten that.

>
>> 2) There are more, or different, internal kinds of strings, which affect
>> the processing patterns.
> This is the basic idea of PEP 393.

Agreed.
>
>> a) all ASCII
>> b) latin-1 (8-bit codepoints, the first 256 Unicode codepoints) This
>> kind may not be able to support a "mostly" variation, and may be no more
>> efficient than case b).  But it might also be popular in parts of Europe
> This two cases are already in PEP 393.
Sure.  Wanted to enumerate all, rather than just add-ons.

>> c) mostly ASCII (utf8) with clever indexing/caching to be efficient
>> d) UTF-8 with clever indexing/caching to be efficient
> I see neither a need nor a means to consider these.

The discussion about "mostly ASCII" strings seems convincing that there 
could be a significant space savings if such were implemented.

>> e) 16-bit codepoints
> These are in PEP 393.
>
>> f) UTF-16 with clever indexing/caching to be efficient
> Again, -1.

This is probably the one I would pick as least likely to be useful if 
the rest were implemented.

>> g) 32-bit codepoints
> This is in PEP 393.
>
>> h) UTF-32
> What's that, as opposed to g)?

g) would permit codes greater than u+10ffff and would permit the illegal 
codepoints and lone surrogates.  h) would be strict Unicode 
conformance.  Sorry that the 4 paragraphs of explanation that you didn't 
quote didn't make that clear.

> I'm not open to revise PEP 393 in the direction of adding more
> representations.
>
It's your PEP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110824/8200a71c/attachment.html>