[Python-Dev] PyPy 1.7 - widening the sweet spot (original) (raw)
Amaury Forgeot d'Arc amauryfa at gmail.com
Wed Nov 23 00:00:07 CET 2011
- Previous message: [Python-Dev] PyPy 1.7 - widening the sweet spot
- Next message: [Python-Dev] PyPy 1.7 - widening the sweet spot
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message: [Python-Dev] PyPy 1.7 - widening the sweet spot
- Next message: [Python-Dev] PyPy 1.7 - widening the sweet spot
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]