<div class="gmail_quote">2011/11/21 Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu">tjreedy@udel.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":51e">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<br>
</div></blockquote></div><br>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.<div><br></div><div>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.</div>
<div><br></div><div>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.<br clear="all">
<div><br></div>-- <br>Amaury Forgeot d'Arc<br>
</div>