pep-550: Fix typos (#336)
This commit is contained in:
parent
3c3d9274b4
commit
fd0f25e2dc
36
pep-0550.rst
36
pep-0550.rst
|
@ -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.
|
||||||
|
|
Loading…
Reference in New Issue