Merge pull request #6 from pradyunsg/typos

Fix a few typos and change form of some words

doc/bad_api.rst

@@ -32,8 +32,8 @@ crashes when misused. Recent example of CPython bug: `bpo-25750: crash in
 type_getattro() <https://bugs.python.org/issue25750>`_.
 
 Borrowed references are a problem whenever there is no reference to borrow:
-they assume that a reified object already exists (and thus have a positive
-refcout), so that it is just borrowed.
+they assume that a referenced object already exists (and thus have a positive
+refcount), so that it is just borrowed.
 
 :ref:`Tagged pointers <tagged-pointer>` are an example of this: since there is
 no concrete ``PyObject*`` to represent the integer, it cannot easily be
@@ -138,7 +138,7 @@ Py_TYPE() corner case
 ---------------------
 
 Technically, ``Py_TYPE()`` returns a borrowed reference to a ``PyTypeObject*``.
-In pratice, for heap types, an instance holds already a strong reference
+In practice, for heap types, an instance holds already a strong reference
 to the type in ``PyObject.ob_type``. For static types, instances use a borrowed
 reference, but static types are never destroyed.
 
@@ -180,7 +180,7 @@ Bad? implementations for concrete types. Examples:
 Implementations for concrete types don't *have to* be part of the C API.
 Moreover, using directly them introduce bugs when the caller pass a subtype.
 For example, PyDict_GetItem() **must not** be used on a dict subtype, since
-``__getitem__()`` be be overriden for good reasons.
+``__getitem__()`` be be overridden for good reasons.
 
 
 Functions kept for backward compatibility
@@ -265,7 +265,7 @@ Example of macros:
 PyType_Ready() and setting directly PyTypeObject fields
 =======================================================
 
-* ``PyTypeObject`` structure should become opaquet
+* ``PyTypeObject`` structure should become opaque
 * ``PyType_Ready()`` should be removed
 
 See :ref:`Implement a PyTypeObject in C <impl-pytype>` for the rationale.

doc/cpyext.rst

@@ -7,7 +7,7 @@ PyPy cpyext module
 cpyext is the implementation of the C API in `PyPy <https://pypy.org/>`__.
 
 See Ronan Lamy's talk `Adventures in compatibility emulating CPython's C API in
-PyPy <https://www.youtube.com/watch?v=qH0eeh-4XE8>`_ (Youtube video) at
+PyPy <https://www.youtube.com/watch?v=qH0eeh-4XE8>`_ (YouTube video) at
 EuroPython 2018.
 
 Source

doc/gilectomy.rst

@@ -20,9 +20,9 @@ Gilectomy has multiple issues, but the two main issues are:
 
 For "Gilectomy 2.0", Hastings will be looking at using a tracing garbage
 collector (GC), rather than the CPython GC that is based on reference counts.
-Tracing GCs are more multicore friendly, but he doesn't know anything about
+Tracing GCs are more multi-core friendly, but he doesn't know anything about
 them. He also would rather not write his own GC.
 
 * https://github.com/larryhastings/gilectomy
 * May 2018: https://lwn.net/Articles/754577/
-* Pycon US 2017: https://speakerdeck.com/pycon2017/larry-hastings-the-gilectomy-hows-it-going
+* PyCon US 2017: https://speakerdeck.com/pycon2017/larry-hastings-the-gilectomy-hows-it-going

doc/new_api.rst

@@ -105,7 +105,7 @@ would become::
 
 or maybe even::
 
-    PyObject* PyList_GET_ITEM(PyObjcet *op, PyObject *i) { return PyList_GetItem(op, i); }
+    PyObject* PyList_GET_ITEM(PyObject *op, PyObject *i) { return PyList_GetItem(op, i); }
 
 Adding a **new** ``PyList_GET_ITEM()`` **function** would make the ABI larger,
 whereas the ABI should become smaller.

doc/old_c_api.rst

@@ -13,7 +13,7 @@ use cases like :ref:`Cython <cython>` (for best performances) and
 :ref:`debugging tools <debug-tools>`, but also for the long tail of C
 extensions on PyPI.
 
-See also :ref:`Calling conventensions <calling-conventions>`.
+See also :ref:`Calling conventions <calling-conventions>`.
 
 What is the Python C API?
 =========================

doc/optimization_ideas.rst

@@ -30,10 +30,10 @@ There are discussing to use a tracing garbage collector for CPython, but this
 idea remains highly hypothetical since it very likely require deep changes in
 the C API, which is out of the scope of the :ref:`new C API project
 <new-c-api>`. The main risk is to break too many C extensions which would make
-this idea unsuable in practice.
+this idea unusable in practice.
 
 It may be possible to emulate reference counting for the C API. Py_INCREF() and
-Py_DECREF() would be reimplemented using an hash table: object => reference
+Py_DECREF() would be re-implemented using an hash table: object => reference
 counter.
 
 Larry Hastings consider to use a tracing garbage collector for :ref:`Gilectomy
@@ -51,7 +51,7 @@ smaller locks, maybe one lock per Python object.
 
 Jython has not GIL.
 
-Reference couting remains a good and convenient API for C extension. Maybe this
+Reference counting remains a good and convenient API for C extension. Maybe this
 design can be kept for the public C API for external C extensions, but CPython
 internals can be modified to avoid reference counting, like using a tracing
 garbage collector for example. Once the C API stops leaking implementation
@@ -60,11 +60,11 @@ details, many new options become possible.
 Gilectomy project is CPython 3.6 fork which tries to remove the GIL. In 2017,
 the project did not succeed yet to scale linearly performances with the number
 of threads. It seems like **reference counting is a performance killer** for
-multithreading.
+multi-threading.
 
 By the way, using atomic operations to access (increase in ``Py_INCREF()``,
 decrease and test in ``Py_DECREF()``) the reference count has been proposed,
-but experiment showed a slowdown of 20% on single threaded microbenchmarks.
+but experiment showed a slowdown of 20% on single threaded micro-benchmarks.
 
 
 .. _tagged-pointer:
@@ -77,7 +77,7 @@ See `Wikipedia: Tagged pointer
 
 Tagged pointers are used by MicroPython to reduce the memory footprint.
 
-Using tagged pointers is a common optimization technic to reduce the
+Using tagged pointers is a common optimization technique to reduce the
 boxing/unboxing cost and to reduce the memory consumption.
 
 Currently, it's not possible to implement such optimization, since most of the

doc/os_vendors.rst

@@ -26,7 +26,7 @@ Time scale:
 * A Python release is supported upstream for 5 years.
 * A Fedora release is supported for less than one year.
 * Ubuntu LTS releases are supported for 5 years.
-* Red Hat Entreprise Linux (RHEL) is supported for 10 years, and customers can
+* Red Hat Enterprise Linux (RHEL) is supported for 10 years, and customers can
   subscribe to an extended support up to 15 years.
 
 In 2018, the latest macOS release still only provides Python 2.7 which will

doc/performance.rst

@@ -16,7 +16,7 @@ Hiding implementation details is likely to make tiny loops slower, since it
 adds function calls instead of directly accessing the memory.
 
 The performance slowdown is expected to be negligible, but has to be measured
-once a concrete implmenetation will be written.
+once a concrete implementation will be written.
 
 Question: would it be acceptable to have a new better C API if the average
 slowdown is around 10%? What if the slowdown is up to 25%? Or even 50%?

doc/roadmap.rst

@@ -67,7 +67,7 @@ Timeline
 * 2017-07: Idea proposed on python-ideas. `[Python-ideas] PEP: Hide
   implementation details in the C API
   <https://mail.python.org/pipermail/python-ideas/2017-July/046399.html>`_
-* 2017-05: Idea proposed at the Python Language Summit, during Pycon US 2017.
+* 2017-05: Idea proposed at the Python Language Summit, during PyCon US 2017.
   My `"Python performance" slides (PDF)
   <https://github.com/vstinner/conf/raw/master/2017-PyconUS/summit.pdf>`_.
   LWN article: `Keeping Python competitive

doc/runtimes.rst

@@ -57,7 +57,7 @@ Debug runtime: /usr/bin/python3-dbg
 * Runtime compiled with C assertion: crash (kill itself with SIGABRT signal)
   if a C assertion fails (``assert(...);``).
 * Use the debug hooks on memory allocators by default, as ``PYTHONDEBUG=debug``
-  environment variable: detect memory under- and overflow and misusage of
+  environment variable: detect memory under- and overflow and misuse of
   memory allocators.
 * Compiled without compiler optimizations (``-Og`` or even ``-O0``) to be
   usable with a debugger like ``gdb``: python-gdb.py should work perfectly.

doc/stable_abi.rst

@@ -42,8 +42,8 @@ whereas a debug build uses an offset of **40** instead of **24**, because
 As a consequence, the compiled C extension is incompatible at the ABI level: a
 C extension has to be build twice, once in release mode and once in debug mode.
 
-To reduce the maintaince burden, :ref:`Linux vendors <os-vendors>` only provide
-C extensions compiled in release mode, making the :ref:`debug mode
+To reduce the maintenance burden, :ref:`Linux vendors <os-vendors>` only
+provide C extensions compiled in release mode, making the :ref:`debug mode
 <debug-build>` mostly unusable on Linux in practice.