Remove additional backticks from inline code (#2033)
This commit is contained in:
parent
50d68cd497
commit
5cedff4008
|
@ -120,7 +120,7 @@ Discussion
|
|||
(1, 2) @ (3, 4) @ (5, 6)
|
||||
|
||||
would have to return ``(1, 3, 5) ... (2, 4, 6)``, and *not*
|
||||
``((1, 3), 5) ... ((2, 4), 6)```. This should not require special
|
||||
``((1, 3), 5) ... ((2, 4), 6)``. This should not require special
|
||||
support from the parser, as the outer iterator created by the
|
||||
first ``@`` could easily be taught how to combine itself with
|
||||
ordinary iterators.
|
||||
|
|
12
pep-0543.rst
12
pep-0543.rst
|
@ -936,16 +936,16 @@ unless they have specific reasons to do so.
|
|||
NSS has both process global and per-connection settings for cipher suites. It
|
||||
does not have a concept of SSLContext like OpenSSL. A SSLContext-like behavior
|
||||
can be easily emulated. Specifically, ciphers can be enabled or disabled
|
||||
globally with ```SSL_CipherPrefSetDefault(PRInt32 cipher, PRBool enabled)```,
|
||||
and ```SSL_CipherPrefSet(PRFileDesc *fd, PRInt32 cipher, PRBool enabled)```
|
||||
for a connection. The cipher ```PRInt32``` number is a signed 32bit integer
|
||||
that directly corresponds to an registered IANA id, e.g. ```0x1301```
|
||||
is ```TLS_AES_128_GCM_SHA256```. Contrary to OpenSSL, the preference order
|
||||
globally with ``SSL_CipherPrefSetDefault(PRInt32 cipher, PRBool enabled)``,
|
||||
and ``SSL_CipherPrefSet(PRFileDesc *fd, PRInt32 cipher, PRBool enabled)``
|
||||
for a connection. The cipher ``PRInt32`` number is a signed 32bit integer
|
||||
that directly corresponds to an registered IANA id, e.g. ``0x1301``
|
||||
is ``TLS_AES_128_GCM_SHA256``. Contrary to OpenSSL, the preference order
|
||||
of ciphers is fixed and cannot be modified at runtime.
|
||||
|
||||
Like SecureTransport, NSS has no API for aggregated entries. Some consumers
|
||||
of NSS have implemented custom mappings from OpenSSL cipher names and rules
|
||||
to NSS ciphers, e.g. ```mod_nss```.
|
||||
to NSS ciphers, e.g. ``mod_nss``.
|
||||
|
||||
|
||||
Proposed Interface
|
||||
|
|
|
@ -889,7 +889,7 @@ converted to an instance attributes constraint as follows:
|
|||
- if only the double star attribute constraints subpattern is present, matching
|
||||
proceeds as if for the equivalent instance attributes constraint.
|
||||
- if there are more positional subpatterns than the length of
|
||||
``__match_args__``` (as obtained using ``len()``), ``TypeError`` is raised.
|
||||
``__match_args__`` (as obtained using ``len()``), ``TypeError`` is raised.
|
||||
- Otherwise, positional pattern ``i`` is converted to an attribute pattern
|
||||
using ``__match_args__[i]`` as the attribute name.
|
||||
- if any element in ``__match_args__`` is not a string, ``TypeError`` is raised.
|
||||
|
@ -2058,7 +2058,7 @@ Relative to PEP 634 this PEP makes the following key changes:
|
|||
* class patterns treat any class that sets ``__match_args__`` to ``None`` as
|
||||
accepting a single positional pattern that is matched against the entire
|
||||
object (avoiding the special casing required in PEP 634)
|
||||
* class patterns raise ``TypeError` when used with an object that does not
|
||||
* class patterns raise ``TypeError`` when used with an object that does not
|
||||
define ``__match_args__``
|
||||
* dedicated syntax for ducktyping is added, such that ``case cls{...}:`` is
|
||||
roughly equivalent to ``case cls(**{...}):``, but skips the check for the
|
||||
|
|
|
@ -314,10 +314,10 @@ Conditionally Applying TypeGuard Type
|
|||
It was suggested that the expression passed as the first argument to a type
|
||||
guard function should retain its existing type if the type of the expression was
|
||||
a proper subtype of the type specified in the TypeGuard return type.
|
||||
For example, if the type guard function is ```def f(value: object) ->
|
||||
TypeGuard[float]``` and the expression passed to this function is of type
|
||||
```int```, it would retain the ```int``` type rather than take on the
|
||||
```float``` type indicated by the TypeGuard return type. This proposal was
|
||||
For example, if the type guard function is ``def f(value: object) ->
|
||||
TypeGuard[float]`` and the expression passed to this function is of type
|
||||
``int``, it would retain the ``int`` type rather than take on the
|
||||
``float`` type indicated by the TypeGuard return type. This proposal was
|
||||
rejected because it added complexity, inconsistency, and opened up additional
|
||||
questions about the proper behavior if the type of the expression was of
|
||||
composite types like unions or type variables with multiple constraints. It was
|
||||
|
|
|
@ -215,7 +215,7 @@ Frontends must execute ``get_requires_for_build_editable`` hooks in
|
|||
an environment which contains the bootstrap requirements specified in the
|
||||
``pyproject.toml`` file.
|
||||
|
||||
Frontends must execute the ````prepare_metadata_for_build_editable`` and
|
||||
Frontends must execute the ``prepare_metadata_for_build_editable`` and
|
||||
``build_editable`` hooks in an environment which contains the bootstrap
|
||||
requirements from ``pyproject.toml`` and those specified by the
|
||||
``get_requires_for_build_editable`` hook.
|
||||
|
|
|
@ -120,7 +120,7 @@ To be removed:
|
|||
* String exceptions: use instances of an Exception class [2]_ [done]
|
||||
* ``raise Exception, "message"``: use ``raise Exception("message")`` [12]_
|
||||
[done]
|
||||
* ```x```: use ``repr(x)`` [2]_ [done]
|
||||
* ``x``: use ``repr(x)`` [2]_ [done]
|
||||
* The ``<>`` operator: use ``!=`` instead [3]_ [done]
|
||||
* The __mod__ and __divmod__ special methods on float. [they should stay] [21]_
|
||||
* Drop unbound methods [7]_ [25]_ [done]
|
||||
|
|
Loading…
Reference in New Issue