2011/11/22 Terry Reedy <tjreedy at udel.edu>
> On 11/22/2011 3:28 PM, Philip Jenvey wrote:
>
> One reason to target 3.2 for now is it's not a moving target.
>>
>
> Neither is the basic design and behavior of the new unicode
> implementation. On 3.2 narrow builds, including Windows
>
> >>> len('\U00010101')
> 2
>
> With 3.3, the answer will be, properly, 1. I suspect that becoming
> compatible with that, and all that it implies for many other examples, will
> be the biggest hurdle for PyPy becoming compatible with 3.3.
PyPy currently defines unicode as arrays of wchar_t, so only Windows uses a
narrow unicode build.
It will probably change though, and for performance reasons it makes indeed
sense to have different internal representations for the same external type.
PyPy already does this for several types (there is a special version of
dict specialized for string keys, and the 2.7 range() returns a list that
does not need to allocate its items, and can turn into a "real" list as
soon as you modify it), so I would not qualify this task as a big hurdle,
compared to other optimizations done in similar areas.
--
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20111123/0995d98c/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4