Fix some syntax issues preventing code literal rendering

This commit is contained in:
Brett Cannon 2016-10-28 14:20:14 -07:00 committed by GitHub
parent d5969080c7
commit 308477cea7
1 changed files with 3 additions and 3 deletions

View File

@ -143,14 +143,14 @@ or falling back to an alternative input, has shrunk to two uses of the ``?``
symbol and two uses of the ``?else`` keyword.
In the first two examples, the 31 character boilerplate clause
`` if exprN is not None else None`` (minimally 27 characters for a single letter
``if exprN is not None else None`` (minimally 27 characters for a single letter
variable name) has been replaced by a single ``?`` character, substantially
improving the signal-to-pattern-noise ratio of the lines (especially if it
encourages the use of more meaningful variable and field names rather than
making them shorter purely for the sake of expression brevity).
In the last example, two instances of the 21 character boilerplate,
`` if exprN is not None`` (minimally 17 characters) are replaced with single
``if exprN is not None`` (minimally 17 characters) are replaced with single
characters, again substantially improving the signal-to-pattern-noise ratio.
Furthermore, each of our 5 "subexpressions of potential interest" is included
@ -162,7 +162,7 @@ clear conceptual basis for the existence checking attribute access and
subscripting operators:
* ``obj?.attr`` is roughly equivalent to ``obj ?then obj.attr``
* ``obj?[expr]``is roughly equivalent to ``obj ?then obj[expr]``
* ``obj?[expr]`` is roughly equivalent to ``obj ?then obj[expr]``
The main semantic difference between the shorthand forms and their expanded
equivalents is that the common subexpression to the left of the existence