pep-550: Fix typos (#336)

This commit is contained in:
Yury Selivanov 2017-08-12 00:17:03 -04:00 committed by GitHub
parent 3c3d9274b4
commit fd0f25e2dc
1 changed files with 19 additions and 17 deletions

View File

@ -55,10 +55,11 @@ the following generator::
Decimal context is using a TLS to store the state, and because TLS is Decimal context is using a TLS to store the state, and because TLS is
not aware of generators, the state can leak. The above code will not aware of generators, the state can leak. The above code will
not work correctly, if a user iterates over the ``calculate()`` not work correctly, if a user iterates over the ``calculate()``
generator with different precisions in parallel:: generator with different precisions one by one using a ``zip()``
built-in, for example::
g1 = calculate(100) g1 = calculate(precision=100)
g2 = calculate(50) g2 = calculate(precision=50)
items = list(zip(g1, g2)) items = list(zip(g1, g2))
@ -67,7 +68,7 @@ generator with different precisions in parallel::
# first value from g2 calculated with 50 precision. # first value from g2 calculated with 50 precision.
# #
# items[1] will be a tuple of: # items[1] will be a tuple of:
# second value from g1 calculated with 50 precision, # second value from g1 calculated with 50 precision (!!!),
# second value from g2 calculated with 50 precision. # second value from g2 calculated with 50 precision.
An even scarier example would be using decimals to represent money An even scarier example would be using decimals to represent money
@ -412,11 +413,11 @@ save a reference to the current execution context when they are
instantiated. The have the same implementation of ``.send()`` and instantiated. The have the same implementation of ``.send()`` and
``.throw()`` methods. ``.throw()`` methods.
The only difference is that The only difference is that ``gi_isolated_execution_context``
``gi_isolated_execution_context`` is always set to ``True``, and is always set to ``True``, and is never modified by the interpreter.
is never modified by the interpreter. ``yield from o`` expression in ``yield from o`` expression in regular generators that are not
regular generators that are not decorated with ``types.coroutine``, decorated with ``types.coroutine``, is semantically equivalent to
is semantically equivalent to ``for v in o: yield v``. ``for v in o: yield v``.
.. figure:: pep-0550-generators.png .. figure:: pep-0550-generators.png
:align: center :align: center
@ -538,7 +539,9 @@ Python
2. ``sys.set_execution_context_item(key, value)``: set 2. ``sys.set_execution_context_item(key, value)``: set
``key``/``value`` item for the current Execution Context. ``key``/``value`` item for the current Execution Context.
If ``value`` is ``None``, the item will be removed. If ``value`` is ``None``, the item will be removed
(read more about it in
`Why setting a key to None removes the item?`_.)
3. ``sys.get_execution_context()``: return the current Execution 3. ``sys.get_execution_context()``: return the current Execution
Context object: ``sys.ExecutionContext``. Context object: ``sys.ExecutionContext``.
@ -554,8 +557,7 @@ Python
mutable mapping API, abstracting away the real immutable mutable mapping API, abstracting away the real immutable
``PyExecContextData``. ``PyExecContextData``.
* ``ExecutionContext()``: construct a new, empty, execution * ``ExecutionContext()``: create a new, empty, execution context.
context.
* ``ec.run(func, *args)`` method: run ``func(*args)`` in the * ``ec.run(func, *args)`` method: run ``func(*args)`` in the
``ec`` execution context. Any changes to the Execution Context ``ec`` execution context. Any changes to the Execution Context
@ -605,8 +607,8 @@ on the low-level immutable ``PyExecContextData`` object.
6. ``PyExecContext_SetItem`` and ``PyExecContext_GetItem``. 6. ``PyExecContext_SetItem`` and ``PyExecContext_GetItem``.
The exact layout ``PyExecContextData`` is private, which allows The exact layout of ``PyExecContextData`` is private, which allows
to switch it to a different implementation later. More on that us to switch it to a different implementation later. More on that
in the `Implementation Details`_ section. in the `Implementation Details`_ section.
@ -680,11 +682,11 @@ Generators and Coroutines
Using a microbenchmark for generators and coroutines from :pep:`492` Using a microbenchmark for generators and coroutines from :pep:`492`
([12]_), it was possible to observe 0.5 to 1% performance degradation. ([12]_), it was possible to observe 0.5 to 1% performance degradation.
asyncio echoserver microbechmarks from the uvloop project [13]_ asyncio "echo server" microbechmarks from the uvloop project [13]_
showed 1-1.5% performance degradation for asyncio code. showed 1-1.5% performance degradation for asyncio code.
asyncpg benchmarks [14]_, that execute more code and are closer to a asyncpg benchmarks [14]_, that execute more code and are closer to a
real-world application did not exhibit any noticeable performance real-world application, did not exhibit any noticeable performance
change. change.
@ -733,7 +735,7 @@ items, HAMT is a bit slower than Python dict/shallow copy.
Figure 6. Benchmark code can be found here: [10]_. Figure 6. Benchmark code can be found here: [10]_.
Figure 6 below shows comparison of lookup costs between Python dict Figure 6 shows comparison of lookup costs between Python dict
and an HAMT immutable mapping. HAMT lookup time is 30-40% worse and an HAMT immutable mapping. HAMT lookup time is 30-40% worse
than Python dict lookups on average, which is a very good result, than Python dict lookups on average, which is a very good result,
considering how well Python dicts are optimized. considering how well Python dicts are optimized.