Author: Antonio Cuni <anto.c...@gmail.com> Branch: extradoc Changeset: r5893:5d37d9c4714b Date: 2018-09-02 18:31 +0200 http://bitbucket.org/pypy/extradoc/changeset/5d37d9c4714b/
Log: this is the correct ReST way to write literals diff --git a/blog/draft/2018-09-cpyext/cpyext.rst b/blog/draft/2018-09-cpyext/cpyext.rst --- a/blog/draft/2018-09-cpyext/cpyext.rst +++ b/blog/draft/2018-09-cpyext/cpyext.rst @@ -8,14 +8,14 @@ this blog post is to explain some of these technical details, so that we can simply link here instead of explaing again and again :). -From a 10.000 foot view, cpyext is PyPy's version of `"Python.h"`: every time +From a 10.000 foot view, cpyext is PyPy's version of ``"Python.h"``: every time you compile and extension which uses that header file, you are using cpyext: -this includes extension explicitly written in C (such as `numpy`) and +this includes extension explicitly written in C (such as ``numpy``) and extensions which are generated from other compilers/preprocessors -(e.g. `Cython`). +(e.g. ``Cython``). At the time of writing, the current status is that most C extensions "just -work": generally speaking, you can simply `pip install` all of them, provided +work": generally speaking, you can simply ``pip install`` all of them, provided they use the public, `official C API`_ instead of poking at private implementation details. @@ -35,7 +35,7 @@ object, you allocate a block of memory of the appropriate size on the heap: depending on the details you might end up calling different allocators, but for the sake of simplicity, you can think that this ends up being a call to -`malloc()`. Handles to objects have the C type `PyObject *`, which point to +``malloc()``. Handles to objects have the C type ``PyObject *``, which point to the memory just allocated: this address never changes during the object lifetime, and the C code can freely pass it around, store it inside containers, retrieve it later, etc. @@ -45,7 +45,7 @@ decrement_ reference counter accordingly. When the reference counter goes to 0, it means that the object is no longer used by anyone and can safely be destroyed. Again, we can simplify and say that this results in a call to -`free()`, which finally releases the memory which was allocated by `malloc()`. +``free()``, which finally releases the memory which was allocated by ``malloc()``. .. _increment: https://docs.python.org/2/c-api/refcounting.html#c.Py_INCREF .. _decrement: https://docs.python.org/2/c-api/refcounting.html#c.Py_DECREF @@ -56,9 +56,9 @@ - you create, either directly or indirectly, lots of objects; - most of these objects are temporary and very short-lived: think e.g. of - doing `a + b + c`: you need to allocate an object to hold the temporary - result of `a + b`, but it dies very quickly because you no longer need it - when you do the final `+ c` part; + doing ``a + b + c``: you need to allocate an object to hold the temporary + result of ``a + b``, but it dies very quickly because you no longer need it + when you do the final ``+ c`` part; - only small fraction of the objects survives and stay around for a while. @@ -84,9 +84,7 @@ In practice, this scheme works very well and it is one of the reasons why PyPy is much faster than CPython. However, careful readers have surely noticed -that this is a problem for `cpyext`: on one hand, we have PyPy objects which +that this is a problem for ``cpyext``: on one hand, we have PyPy objects which can potentially move and change their underlying memory address; on the other -hand, we need a way to represent them as fixed-address `PyObject *` when we +hand, we need a way to represent them as fixed-address ``PyObject *`` when we pass them to C extensions. We surely need a way to handle that. - - _______________________________________________ pypy-commit mailing list pypy-commit@python.org https://mail.python.org/mailman/listinfo/pypy-commit
