Maciej Fijalkowski, 22.11.2011 15:46: > On Tue, Nov 22, 2011 at 3:15 PM, Stefan Behnel wrote: >> Giampaolo Rodolà, 22.11.2011 10:21: >>> 2011/11/21 Terry Reedy: >>>> >>>> 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 >>> >>> Is there a reason in particular? >> >> Well, Py3 still has a lot to catch up in terms of wide spread distribution >> compared to Py2.x, and new users will usually start using the most up to >> date release, which will soon be 3.3. >> >> Besides, 3.3 has received various optimisations that make it more suitable >> for production use than 3.2, including the above mentioned Unicode >> optimisations. Note that I was referring to Terry's "more production use" comment here, not to the "PyPy should target 3.3 instead of 3.2" part. > PyPy's py3k branch targets Python 3.2 until 3.3 is released and very > likely 3.3 afterwards. Optimizations are irrelevant really in the case > of PyPy. I admit that I wasn't very clear in my wording. As Terry pointed out, the Unicode changes in Py3.3 are not only for speed and/or memory performance improvements, they also improve the compliance of the Unicode implementation, which implies a behavioural change. Since PyPy appears to have implemented the current wide/narrow behaviour of Py2 and Py3.[012] already, I see no reason not to target 3.2 for the time being as it does not require substantial changes in this part. Compliance with Py3.3 will then require implementing the new behaviour. Stefan
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