[pypy-commit] extradoc extradoc: tweaks

[mattip]

Author: Matti Picus <matti.picus at gmail.com>
Branch: extradoc
Changeset: r5970:128bb83a6384
Date: 2019-12-17 20:08 +0200
http://bitbucket.org/pypy/extradoc/changeset/128bb83a6384/

Log:	tweaks

diff --git a/blog/draft/2019-12-hpy-sprint.rst b/blog/draft/2019-12-hpy-sprint.rst
--- a/blog/draft/2019-12-hpy-sprint.rst
+++ b/blog/draft/2019-12-hpy-sprint.rst
@@ -38,10 +38,10 @@
      visible nor accessible using the API, so each implementation if free to
      use what fits best.
 
-The other major design goal of HPy is to allow an incremental
-transition/porting, so existing modules can migrate their codebase one method
-at a time.  Moreover, Cython eventually will generate HPy code, so extension
-module written in Cython will be able to benefit from HPy automatically.
+The other major design goal of HPy is to allow incremental transition and
+porting, so existing modules can migrate their codebase one method at a time.
+Moreover, Cython eventually will generate HPy code, so extension module written
+in Cython will be able to benefit from HPy automatically.
 
 More details can be found in the README of the official `HPy repository`_.
 
@@ -53,22 +53,22 @@
 Target ABI
 -----------
 
-When compiling an HPy extension you can choose two different target ABIs:
+When compiling an HPy extension you can choose one of two different target ABIs:
 
   - **HPy/CPython ABI**: in this case, ``hpy.h`` contains a set of macros and
-    static inline functions which at compilation time translates the HPy API
-    into the standard C-API: the compiled module will have no performance
-    penalty and it will have an filename like
+    static inline functions. At compilation time this translates the HPy API
+    into the standard C-API. The compiled module will have no performance
+    penalty, and it will have a "standard" filename like
     ``foo.cpython-37m-x86_64-linux-gnu.so``.
 
   - **Universal HPy ABI**: as the name implies, extension modules compiled
     this way are "universal" and can be loaded unmodified by multiple Python
-    interpreters and version.  Moreover, it will be possible to dynamically
+    interpreters and versions.  Moreover, it will be possible to dynamically
     enable a special debug mode which will make it easy to find e.g., open
     handles or memory leaks, **without having to recompile the extension**.
 
 
-Universal modules can be loaded **also** on CPython, thanks to the
+Universal modules can **also** be loaded on CPython, thanks to the
 ``hpy_universal`` module which is under development. An extra layer of
 indirection enables loading extensions compiled with the universal ABI. Users
 of ``hpy_universal`` will face a small performance penalty compared to the ones
@@ -76,15 +76,15 @@
 
 This setup gives several benefits:
 
-  - extension developers can use the extra debug features given by the
-    Universal ABI with no need to use a special debug version of Python
+  - Extension developers can use the extra debug features given by the
+    Universal ABI with no need to use a special debug version of Python.
 
-  - projects which need the maximum level of performance can compile their
-    extension for each relevant version of CPython, as they are doing now
+  - Projects which need the maximum level of performance can compile their
+    extension for each relevant version of CPython, as they are doing now.
 
-  - projects for which runtime speed is less important will have the choice of
+  - Projects for which runtime speed is less important will have the choice of
     distributing a single binary which will work on any version and
-    implementation of Python
+    implementation of Python.
 
 
 A simple example
@@ -132,7 +132,7 @@
     }
 
 
-People who are familiar with the current C-API will surely notice lots of
+People who are familiar with the current C-API will surely notice many
 similarities. The biggest differences are:
 
   - Instead of ``PyObject *``, objects have the type ``HPy``, which as
@@ -174,7 +174,7 @@
      input for parts of the projects which are automatically
      generated. Currently, this lives `public_api.h`_.
 
-  2. A set of header files which can be used to compile extension module:
+  2. A set of header files which can be used to compile extension modules:
      depending on whether the flag ``-DHPY_UNIVERSAL_ABI`` is passed to the
      compiler, the extension can target the `HPy/CPython ABI`_ or the `HPy
      Universal ABI`_
@@ -194,7 +194,7 @@
 
 Moreover, we started a `PyPy branch`_ in which to implement the
 ``hpy_univeral`` module: at the moment of writing PyPy can pass all the HPy
-tests apart the ones which allows to convert to and from ``PyObject *``.
+tests apart the ones which allow conversion to and from ``PyObject *``.
 Among the other things, this means that it is already possible to load the
 very same binary module in both CPython and PyPy, which is impressive on its
 own :).
@@ -212,7 +212,7 @@
   - it uses only a small subset of the Python API
 
 This repo contains the `HPy port of ultrajson`. This commit_ shows an example
-of how the porting looks like.
+of what the porting looks like.
 
 ``ujson_hpy`` is also a very good example of incremental migration: so far
 only ``ujson.loads`` is implemented using the HPy API, while ``ujson.dumps``
@@ -294,26 +294,26 @@
 ---------------------------------
 
 We think we can be very satisfied about what we have got so far. The
-development of HPy just started but these early results seem to indicate that
+development of HPy is quite new, but these early results seem to indicate that
 we are on the right track to bring Python extensions into the future.
 
 At the moment, we can anticipate some of the next steps in the development of
 HPy:
 
-  - think about a proper API design: what we have done so far has
+  - Think about a proper API design: what we have done so far has
     been a "dumb" translation of the API we needed to run ``ujson``. However,
     one of the declared goal of HPy is to improve the design of the API. There
     will be a trade-off between the desire of having a clean, fresh new API
     and the need to be not too different than the old one, to make porting
     easier.  Finding the sweet spot will not be easy!
 
-  - implement the "debug" mode, which will help developers to find
-    bugs such as leaking handles or using invalid handles
+  - Implement the "debug" mode, which will help developers to find
+    bugs such as leaking handles or using invalid handles.
 
-  - instruct Cython to emit HPy code on request
+  - Instruct Cython to emit HPy code on request.
 
-  - eventually, we will also want to try to port parts of ``numpy`` to HPy to
+  - Eventually, we will also want to try to port parts of ``numpy`` to HPy to
     finally solve the long-standing problem of sub-optimal ``numpy``
-    performance in PyPy
+    performance in PyPy.
 
 Stay tuned!