[Python-Dev] PyPy 1.7 - widening the sweet spot

[Amaury Forgeot d'Arc]

2011/11/21 Terry Reedy <tjreedy at udel.edu>

> I strongly recommend that where it makes a difference, the pypy python3
> project target 3.3. In particular, don't reproduce the buggy narrow-build
> behavior of 3.2 and before (perhaps pypy avoids this already). Do include
> the new unicode capi in cpyext. I anticipate that 3.3 will see more
> production use than 3.2
>

In the current 2.7-compatible version, PyPy already uses wchar_t for its
Unicode string, i.e. it is always a wide build with gcc and a narrow build
on Windows.

But this will certainly change for the 3.x port. PyPy already supports
different internal representations for the same visible user type, and it
makes sense to have 1-byte, 2-bytes and 4-bytes unicode types and try to
choose the most efficient representation.

As for the C API... getting a pointer out of a PyPy string already requires
to allocate and fill a new non-movable buffer (since all memory allocated
by PyPy is movable).  So cpyext could support the new API for sure, but
it's unlikely to give any performance benefit to an extension module.

-- 
Amaury Forgeot d'Arc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20111121/75fd7476/attachment.html>