Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Fri, Nov 25, 2011 at 12:37, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 25 Nov 2011 12:37:59 -0500 Brett Cannon br...@python.org wrote: On Thu, Nov 24, 2011 at 07:46, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski fij...@gmail.com wrote: The problem is not with maintaining the modified directory. The problem was always things like changing interface between the C version and the Python version or introduction of new stuff that does not run on pypy because it relies on refcounting. I don't see how having a subrepo helps here. Indeed, the main thing that can help on this front is to get more modules to the same state as heapq, io, datetime (and perhaps a few others that have slipped my mind) where the CPython repo actually contains both C and Python implementations and the test suite exercises both to make sure their interfaces remain suitably consistent (even though, during normal operation, CPython users will only ever hit the C accelerated version). This not only helps other implementations (by keeping a Python version of the module continuously up to date with any semantic changes), but can help people that are porting CPython to new platforms: the C extension modules are far more likely to break in that situation than the pure Python equivalents, and a relatively slow fallback is often going to be better than no fallback at all. (Note that ctypes based pure Python modules *aren't* particularly useful for this purpose, though - due to the libffi dependency, ctypes is one of the extension modules most likely to break when porting). And the other reason I plan to see this through before I die Uh! Any bad news? :/ Sorry, turn of phrase in English which didn't translate well. I just meant when I get to it, which could quite possibly be a *long* time from now. This year has been absolutely insane for me personally (if people care, the details are shared on Google+ or you can just ask me), so I am just not promising anything for Python on a short timescale (although I'm still hoping the final details for bootstrapping importlib won't be difficult to work out so I can meet a personal deadline of PyCon). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
Le 25/11/2011 19:21, Amaury Forgeot d'Arc a écrit : And oh, I almost forgot distutils, which needs to parse some Makefile which of course does not exist in PyPy. This is a bug (#10764) that I intend to fix for the next releases of 2.7 and 3.2. I also want to fix all modules that use sys.version[:2] to get 'X.Y', which is a CPython implementation detail. I find PyPy and excellent project, so you can send any bugs in distutils, sysconfig, site and friends my way! I also hope to make distutils2 compatible with PyPy before 2012. Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Thu, Nov 24, 2011 at 07:46, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski fij...@gmail.com wrote: The problem is not with maintaining the modified directory. The problem was always things like changing interface between the C version and the Python version or introduction of new stuff that does not run on pypy because it relies on refcounting. I don't see how having a subrepo helps here. Indeed, the main thing that can help on this front is to get more modules to the same state as heapq, io, datetime (and perhaps a few others that have slipped my mind) where the CPython repo actually contains both C and Python implementations and the test suite exercises both to make sure their interfaces remain suitably consistent (even though, during normal operation, CPython users will only ever hit the C accelerated version). This not only helps other implementations (by keeping a Python version of the module continuously up to date with any semantic changes), but can help people that are porting CPython to new platforms: the C extension modules are far more likely to break in that situation than the pure Python equivalents, and a relatively slow fallback is often going to be better than no fallback at all. (Note that ctypes based pure Python modules *aren't* particularly useful for this purpose, though - due to the libffi dependency, ctypes is one of the extension modules most likely to break when porting). And the other reason I plan to see this through before I die is to help distribute the maintenance burden. Why should multiple VMs fix bad assumptions made by CPython in their own siloed repos and then we hope the change gets pushed upstream to CPython when it could be fixed once in a single repo that everyone works off of? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Fri, 25 Nov 2011 12:37:59 -0500 Brett Cannon br...@python.org wrote: On Thu, Nov 24, 2011 at 07:46, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski fij...@gmail.com wrote: The problem is not with maintaining the modified directory. The problem was always things like changing interface between the C version and the Python version or introduction of new stuff that does not run on pypy because it relies on refcounting. I don't see how having a subrepo helps here. Indeed, the main thing that can help on this front is to get more modules to the same state as heapq, io, datetime (and perhaps a few others that have slipped my mind) where the CPython repo actually contains both C and Python implementations and the test suite exercises both to make sure their interfaces remain suitably consistent (even though, during normal operation, CPython users will only ever hit the C accelerated version). This not only helps other implementations (by keeping a Python version of the module continuously up to date with any semantic changes), but can help people that are porting CPython to new platforms: the C extension modules are far more likely to break in that situation than the pure Python equivalents, and a relatively slow fallback is often going to be better than no fallback at all. (Note that ctypes based pure Python modules *aren't* particularly useful for this purpose, though - due to the libffi dependency, ctypes is one of the extension modules most likely to break when porting). And the other reason I plan to see this through before I die Uh! Any bad news? :/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/25 Brett Cannon br...@python.org On Thu, Nov 24, 2011 at 07:46, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski fij...@gmail.com wrote: The problem is not with maintaining the modified directory. The problem was always things like changing interface between the C version and the Python version or introduction of new stuff that does not run on pypy because it relies on refcounting. I don't see how having a subrepo helps here. Indeed, the main thing that can help on this front is to get more modules to the same state as heapq, io, datetime (and perhaps a few others that have slipped my mind) where the CPython repo actually contains both C and Python implementations and the test suite exercises both to make sure their interfaces remain suitably consistent (even though, during normal operation, CPython users will only ever hit the C accelerated version). This not only helps other implementations (by keeping a Python version of the module continuously up to date with any semantic changes), but can help people that are porting CPython to new platforms: the C extension modules are far more likely to break in that situation than the pure Python equivalents, and a relatively slow fallback is often going to be better than no fallback at all. (Note that ctypes based pure Python modules *aren't* particularly useful for this purpose, though - due to the libffi dependency, ctypes is one of the extension modules most likely to break when porting). And the other reason I plan to see this through before I die is to help distribute the maintenance burden. Why should multiple VMs fix bad assumptions made by CPython in their own siloed repos and then we hope the change gets pushed upstream to CPython when it could be fixed once in a single repo that everyone works off of? PyPy copied the CPython stdlib in a directory named 2.7, which is never modified; instead, adaptations are made by copying the file into modified-2.7, and fixed there. Both directories appear in sys.path This was done for this very reason: so that it's easy to identify the differences and suggest changes to push upstream. But this process was not very successful for several reasons: - The definition of bad assumptions used to be very strict. It's much much better nowadays, thanks to the ResourceWarning in 3.x for example (most changes in modified-2.7 are related to the garbage collector), and wider acceptance by the core developers of the @impl_detail decorators in tests. - 2.7 was already in maintenance mode, and such changes were not considered as bug fixes, so modified-2.7 never shrinks. It was a bit hard to find the motivation to fix only the 3.2 version of the stdlib, which you can not even test with PyPy! - Some modules in the stdlib rely on specific behaviors of the VM or extension modules that are not always easy to implement correctly in PyPy. The ctypes module is the most obvious example to me, but also the pickle/copy modules which were modified because of subtle differences around built-in methods (or was it the __builtins__ module?) And oh, I almost forgot distutils, which needs to parse some Makefile which of course does not exist in PyPy. - Differences between C extensions and pure Python modules are sometimes considered undefined behaviour and are rejected. See issue13274, this one has an happy ending, but I remember that the _pyio.py module chose to not fix some obscure reentrancy issues (which I completely agree with) -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Wed, Nov 23, 2011 at 11:13 PM, Philip Jenvey pjen...@underboss.org wrote: On Nov 22, 2011, at 12:43 PM, Amaury Forgeot d'Arc wrote: 2011/11/22 Philip Jenvey pjen...@underboss.org One reason to target 3.2 for now is it's not a moving target. There's overhead involved in managing modifications to the pure python standard lib needed for PyPy, tracking 3.3 changes as they happen as well exacerbates this. The plans to split the standard lib into its own repo separate from core CPython will of course help alternative implementations here. I don't see how it would help here. Copying the CPython Lib/ directory is not difficult, even though PyPy made slight modifications to the files, and even without any merge tool. Pulling in a separate stdlib as a subrepo under the PyPy repo would certainly make this whole process easier. But you're right, if we track CPython's default branch (3.3) we can make many if not all of the PyPy modifications upstream (until the 3.3rc1 code freeze) instead of in PyPy's modified-3.x directory. Maintaining that modified-3.x dir after every resync can be tedious. -- Philip Jenvey The problem is not with maintaining the modified directory. The problem was always things like changing interface between the C version and the Python version or introduction of new stuff that does not run on pypy because it relies on refcounting. I don't see how having a subrepo helps here. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski fij...@gmail.com wrote: The problem is not with maintaining the modified directory. The problem was always things like changing interface between the C version and the Python version or introduction of new stuff that does not run on pypy because it relies on refcounting. I don't see how having a subrepo helps here. Indeed, the main thing that can help on this front is to get more modules to the same state as heapq, io, datetime (and perhaps a few others that have slipped my mind) where the CPython repo actually contains both C and Python implementations and the test suite exercises both to make sure their interfaces remain suitably consistent (even though, during normal operation, CPython users will only ever hit the C accelerated version). This not only helps other implementations (by keeping a Python version of the module continuously up to date with any semantic changes), but can help people that are porting CPython to new platforms: the C extension modules are far more likely to break in that situation than the pure Python equivalents, and a relatively slow fallback is often going to be better than no fallback at all. (Note that ctypes based pure Python modules *aren't* particularly useful for this purpose, though - due to the libffi dependency, ctypes is one of the extension modules most likely to break when porting). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Nov 22, 2011, at 12:43 PM, Amaury Forgeot d'Arc wrote: 2011/11/22 Philip Jenvey pjen...@underboss.org One reason to target 3.2 for now is it's not a moving target. There's overhead involved in managing modifications to the pure python standard lib needed for PyPy, tracking 3.3 changes as they happen as well exacerbates this. The plans to split the standard lib into its own repo separate from core CPython will of course help alternative implementations here. I don't see how it would help here. Copying the CPython Lib/ directory is not difficult, even though PyPy made slight modifications to the files, and even without any merge tool. Pulling in a separate stdlib as a subrepo under the PyPy repo would certainly make this whole process easier. But you're right, if we track CPython's default branch (3.3) we can make many if not all of the PyPy modifications upstream (until the 3.3rc1 code freeze) instead of in PyPy's modified-3.x directory. Maintaining that modified-3.x dir after every resync can be tedious. -- Philip Jenvey ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/21 Terry Reedy tjre...@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 Is there a reason in particular? --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
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. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Tue, Nov 22, 2011 at 3:15 PM, Stefan Behnel stefan...@behnel.de 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. Stefan 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. Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Nov 22, 2011, at 02:15 PM, Stefan Behnel wrote: 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. 3.3 won't be released (according to PEP 398's current schedule) until August of next year. I think that's too long to wait before pushing for widespread adoption of Python 3. Hopefully, we're going to be making a dent in that in the next version of Ubuntu. We're actively starting to port a handful of desktop applications (including their dependency stacks) to Python 3.2, which I think is a fine release for doing so. I owe a blog post about this, but please do contact me if you want to get involved. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Nov 22, 2011, at 7:35 AM, Stefan Behnel wrote: Maciej Fijalkowski, 22.11.2011 15:46: 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. One reason to target 3.2 for now is it's not a moving target. There's overhead involved in managing modifications to the pure python standard lib needed for PyPy, tracking 3.3 changes as they happen as well exacerbates this. The plans to split the standard lib into its own repo separate from core CPython will of course help alternative implementations here. -- Philip Jenvey ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/22 Philip Jenvey pjen...@underboss.org One reason to target 3.2 for now is it's not a moving target. There's overhead involved in managing modifications to the pure python standard lib needed for PyPy, tracking 3.3 changes as they happen as well exacerbates this. The plans to split the standard lib into its own repo separate from core CPython will of course help alternative implementations here. I don't see how it would help here. Copying the CPython Lib/ directory is not difficult, even though PyPy made slight modifications to the files, and even without any merge tool. OTOH when PyPy changed minor versions (from 2.7.0 to 2.7.2 IIRC) most of the work was to follow the various tiny fixes made to the built-in modules: _io, _ssl and _multiprocessing. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On 11/22/2011 10:35 AM, Stefan Behnel wrote: Maciej Fijalkowski, 22.11.2011 15:46: 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 [snip} 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 behavioral change. One of the major features of Python 3 is the expansion of the directly supported character set from ascii to unicode. Python's original narrow and wide build unicode implementation has problems that were somewhat tolerable in an optional, alternate text class but which are much less so for *the* text class. The general problem is that the two builds give different answers for operations and functions on strings containing non-BMP characters. This differences potentially affects anything that uses strings, such as the re module, without guarding against the differences. One can view the narrow build results as wrong and buggy. Extended chars were practically non-existent when the implementation was written, but are becoming more common now and in the future. In any case, Python string code no longer works the same across all x.y builds. On *nix platforms that can have both narrow and wide builds, there can also be binary conflicts for extension modules. On Windows, there is no conflict because one is stuck with a buggy narrow build. This is all besides the space issue. In my view, Python 3.3 will be the first fully satisfactory Python 3 version. It should be the version of choice for any app doing full unicode text or document processing on platforms that include, in particular, Windows. Since PyPy appears to have implemented the current wide/narrow behavior 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 behavior. Thinking about how PyPy will do that should start well before 3.3 is released. My impression from reading the PyPy and Python 3 page, linked in the original post, is that releasing PyPy fully ready for Python 3, with all listed phases completed, will take close to a year anyway. Hence my comment. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
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.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/22 Terry Reedy tjre...@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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On 11/21/2011 5:36 AM, Maciej Fijalkowski wrote: == PyPy 1.7 - widening the sweet spot == We're pleased to announce the 1.7 release of PyPy. As became a habit, this release brings a lot of bugfixes and performance improvements over the 1.6 release. However, unlike the previous releases, the focus has been on widening the sweet spot of PyPy. That is, classes of Python code that PyPy can greatly speed up should be vastly improved with this release. You can download the 1.7 release here: http://pypy.org/download.html ... The main topic of this release is widening the range of code which PyPy can greatly speed up. On average on our benchmark suite, PyPy 1.7 is around **30%** faster than PyPy 1.6 and up to **20 times** faster on some benchmarks. .. _`pypy 1.7 and cpython 2.7.1`: http://speed.pypy.org If I understand right, pypy is generally slower than cpython without jit and faster with jit. (There is obviously a spurious datapoint in the pypy-c timeline for raytracing-simple.) This site is a nice piece of work. ... .. _`py3k proposal`: http://pypy.org/py3donate.html 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 -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/21 Terry Reedy tjre...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
