On 11/07/2020 00:57, Paul Sokolovsky wrote:
The PEP itself in "rejected" ideas makes an argument against it:
indented stuff after a line ending with ":" must be a *statement*. It
would be totally nuts for that to be something else, e.g. an expression:
Good point.
That of course leads us to the obvious idea:
match a: case 1: ... case 2: ... else: ... Of course, PEP
smartly has an argument against that too, in the vein of "after line
ending with ':', there should be an indent suite (list of
statements)". But that's where it goes sideways.
Exactly. I think not identing what comes after match a: comes with far
more advantages than disadvantages. In fact, if the only "real" issue is
that anything after : must be indented, I'd say it is vastly outweighed
by the issues not doing it would solve.
Would the parser allow us to write the above without the colon, thus
avoiding the aforementioned objection?
And if the above snippet looks weird to anybody, it's only because of
all the "case" business. There wouldn't be such a problem if it was
instead: match a: | 1: ... | 2: ... |: ... The above
ML-like syntax should be perfect for almost everyone, ... except the
PEP authors, because they have it in "rejected ideas" either.
I don't know, that doesn't look very pythonic based on the preference
Python makes for words over symbols. I don't think there's any problem
with using case, it's the expectations many have for what should come
around it that creates issues.
On 11/07/2020 12:49, Greg Ewing wrote:
I can't think of one at the moment, but I don't think you
should dismiss tradition so easily.
I don't mean to dismiss it, but I wouldn't want it to get in the way of
a change if there are good reasons to go against tradition. This seems
like one of these cases to me.
One of the arguments used
to justify significant indentation in Python is that "you're
going to indent it for readability anyway, so the compiler
might as well take notice of it".
For the most part, Python indentation follows what people
would naturally do even if they didn't have to. So I think it's
worth looking at what people typically do in other languages
that don't have mandatory indentation.
[...]
or like this:
switch (x) {
case 1:
...
case 2:
...
default:
...
}
This suggests to me that most people think of the cases as being
subordinate to the switch, and the default being on the same level
as the other cases.
I think that last one would be perceived as ok if it weren't for the
brackets: everyone naturally indents any set of brackets' contents. I
wouldn't normally mind cases being indented extra relative to "match" if
not for two points:
1. Python relies heavily on indentation. It's likely for a match block
to appear in a place that is already well indented, *and* it is also
likely to often include further levels of indentation. It would be
preferable not to require two levels at a minimum every time a match
block is needed.
2. Unless the default case is signalled with an ad-hoc keyword like
default (which I personally would like), it seems a wildcard symbol like
the controversial _ is needed to pair with case. Going against tradition
and setting only one indentation level would solve this issue, while
still allowing (I think) any programmer to indent the default case extra
if they so wish.
If none of this is convincing, I do believe the matter is easier than it
appears, because few would be confused by else being at the same level
as each other case.
Alternatively, what if (gasp!) both were allowed as synonyms? I'm sure
one of the two would eventually settle as conventional, and there is no
possible ambiguity. I know it goes against the "one obvious way to do
it" precept but it's clear that there is no obvious way here at all, so,
¿porque no los dos?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/2U3DRD7R244V7SQ24WRUM34SENA3P5US/
Code of Conduct: http://python.org/psf/codeofconduct/
