Author: Antonio Cuni <[email protected]> Branch: Changeset: r58855:8d263d559191 Date: 2012-11-13 14:18 +0100 http://bitbucket.org/pypy/pypy/changeset/8d263d559191/
Log: various tweaks (mostly english tweaks) diff --git a/pypy/doc/release-2.0.0-beta1.rst b/pypy/doc/release-2.0.0-beta1.rst --- a/pypy/doc/release-2.0.0-beta1.rst +++ b/pypy/doc/release-2.0.0-beta1.rst @@ -5,11 +5,11 @@ We're pleased to announce the 2.0 beta 1 release of PyPy. This release is not a typical beta, in a sense the stability is the same or better than 1.9 and can be used in production. It does however include a few performance -regressions documented below that don't quite make it 2.0 final. +regressions documented below that don't allow us to label is as 2.0 final. -The main features of this release is ARM processor support and the first -release of CFFI-capable PyPy. It also includes numerous improvements -to the numpy in pypy effort, cpyext and performance. +The main features of this release are support for ARM processor and +compatibility with CFFI. It also includes +numerous improvements to the numpy in pypy effort, cpyext and performance. You can download the PyPy 2.0 beta 1 release here: @@ -19,7 +19,7 @@ ============= PyPy is a very compliant Python interpreter, almost a drop-in replacement for -CPython 2.7. It's fast (`pypy 2.0 beta 1 and cpython 2.7.3`_ +CPython 2.7.3. It's fast (`pypy 2.0 beta 1 and cpython 2.7.3`_ performance comparison) due to its integrated tracing JIT compiler. This release supports x86 machines running Linux 32/64, Mac OS X 64 or @@ -36,13 +36,13 @@ Reasons why this is not PyPy 2.0: -* ``ctypes`` fast path is now slower than it used to be. ``ctypes`` in PyPy - 1.9 was either incredibly fast or slower than CPython depending whether +* the ``ctypes`` fast path is now slower than it used to be. In PyPy + 1.9 ``ctypes`` was either incredibly faster or slower than CPython depending whether you hit the fast path or not. Right now it's usually simply slower. We're - probably going to rewrite ``ctypes`` using ``cffi`` which will make it + probably going to rewrite ``ctypes`` using ``cffi``, which will make it universally faster. -* ``cffi``, while very fast is missing one optimization that will make +* ``cffi``, is very fast, but it is missing one optimization that will make it as fast as a native call from C. * ``numpypy`` lazy computation was disabled in the sake of simplicity. We should @@ -52,20 +52,20 @@ ========== * ``cffi`` is officially supported by PyPy. You can install it normally by - using ``pip install cffi`` once you have PyPy installed. Corresponding + using ``pip install cffi`` once you have PyPy installed. The corresponding ``0.4`` version of ``cffi`` has been released. -* ARM is not an officially supported processor architecture. +* ARM is now an officially supported processor architecture. XXX write down few words here * This release contains the latest Python standard library 2.7.3 and is fully compatible with Python 2.7.3. * It does not however contain hash randomization, since the solution present - in CPython is not solving the problem anyway. The reason why can be + in CPython is not solving the problem anyway. The reason can be found on the `CPython issue tracker`_. -* ``gc.get_referrers`` is not faster. +* ``gc.get_referrers`` is not faster. XXX: "not" or "now? * Various numpy improvements. List include: @@ -82,5 +82,7 @@ * ``long`` builtin type is now as fast as CPython's (from roughly 2x slower) -* Unicodes stored in ``dict``/``set``/``list`` are now faster. +* We now have special strategies for ``dict``/``set``/``list`` which contain + unicode strings, which means that now such collections will be both faster + and more compact. _______________________________________________ pypy-commit mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-commit
