Switch my preference to syntax alternative 1.
This commit is contained in:
parent
507c8b78d9
commit
66fb10758e
10
pep-3103.txt
10
pep-3103.txt
|
@ -65,7 +65,7 @@ I'm considering several variants of the syntax first proposed in PEP
|
|||
275 here. There are lots of other possibilities, but I don't see that
|
||||
they add anything.
|
||||
|
||||
My current preference is alternative 2.
|
||||
I've recently been converted to alternative 1.
|
||||
|
||||
I should note that all alternatives here have the "implicit break"
|
||||
property: at the end of the suite for a particular case, the control
|
||||
|
@ -95,7 +95,8 @@ This is the preferred form in PEP 275::
|
|||
SUITE
|
||||
|
||||
The main downside is that the suites where all the action is are
|
||||
indented two levels deep.
|
||||
indented two levels deep; this can be remedied by indenting the cases
|
||||
"half a level" (e.g. 2 spaces if the general indentation level is 4).
|
||||
|
||||
Alternative 2
|
||||
-------------
|
||||
|
@ -112,6 +113,11 @@ the cases::
|
|||
else:
|
||||
SUITE
|
||||
|
||||
Some reasons not to choose this include expected difficulties for
|
||||
auto-indenting editors, folding editors, and the like; and confused
|
||||
users. There are no situations currently in Python where a line
|
||||
ending in a colon is followed by an unindented line.
|
||||
|
||||
Alternative 3
|
||||
-------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue