conflict between alternative proposed syntax and reST markup; escaped with inline literals
This commit is contained in:
parent
f25aa6ef73
commit
a8380d6616
16
pep-0318.txt
16
pep-0318.txt
|
@ -210,14 +210,14 @@ Why [...]?
|
|||
----------
|
||||
|
||||
For syntax options which use a list-like syntax to specify the
|
||||
decorators a few alternatives have been proposed: '[|...|]',
|
||||
'*[...]*', and '<...>'. None have gained traction. The alternatives
|
||||
which involve square brackets only serve to make it obvious that the
|
||||
decorator construct is not a list. They do nothing to make parsing
|
||||
any easier. The '<...>' alternative presents parsing problems because
|
||||
'<' and '>' already parse as un-paired. They present a further
|
||||
parsing ambiguity because a right angle bracket might be a greater
|
||||
than symbol instead of a closer for the decorators.
|
||||
decorators a few alternatives have been proposed: ``[|...|]``,
|
||||
``*[...]*``, and ``<...>``. None have gained traction. The
|
||||
alternatives which involve square brackets only serve to make it
|
||||
obvious that the decorator construct is not a list. They do nothing
|
||||
to make parsing any easier. The '<...>' alternative presents parsing
|
||||
problems because '<' and '>' already parse as un-paired. They present
|
||||
a further parsing ambiguity because a right angle bracket might be a
|
||||
greater than symbol instead of a closer for the decorators.
|
||||
|
||||
|
||||
Current Implementation
|
||||
|
|
Loading…
Reference in New Issue