<br><br><div class="gmail_quote">2011/11/22 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 class="im">On 11/22/2011 3:28 PM, Philip Jenvey wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One reason to target 3.2 for now is it's not a moving target.<br>
</blockquote>
<br></div>
Neither is the basic design and behavior of the new unicode implementation. On 3.2 narrow builds, including Windows<br>
<br>
>>> len('\U00010101')<br>
2<br>
<br>
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.</blockquote><div>
<br></div><div>PyPy currently defines unicode as arrays of wchar_t, so only Windows uses a narrow unicode build. </div><div><br></div><div>It will probably change though, and for performance reasons it makes indeed sense to have different internal representations for the same external type.</div>
<div><br></div></div><div>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.</div>
<div><br></div>-- <br>Amaury Forgeot d'Arc<br>