On 08/07/2020 12:30, Rhodri James wrote:
Any name used as a pattern is a catch-all. The only difference
between "case dummy:" and "case _:" is that "_" doesn't bind to the
thing being matched, but "dummy" does bind to it.
I meant catch-all as in "case _:" (or "else:"). I apologise for the lack
of clarity.
On 08/07/2020 17:02, Guido van Rossum wrote:
There’s one other issue where in the end we could be convinced to
compromise: whether to add an `else` clause in addition to `case
_`. In fact, we probably would already have added it, except for one
detail: it’s unclear whether the `else` should be aligned with `case`
or `match`. If we are to add this we would have to ask the Steering
Council to decide for us, as the authors deadlocked on this question.
Thanks for the write-up. What were the arguments in support of aligning
else with case? I expect it has to be with aesthetics, but for what
concerns semantics, it seems to me that "match...else", interpreted as
"no match was found" would make the most sense; aligning it with case
would look like the else has to do with whatever case was last.
Unless both match and all cases are on the same indentation level. Here
an example:
match:
variable
case "some constant":
# ...
case x if x == guard_clause:
# ...
else:
# ...
I know at least Elm indents the match variable on a separate line.
On 08/07/2020 19:44, Tim Peters wrote:
One microscopic point:
[Guido]
...
(if `.x` is unacceptable, it’s unclear why `^x` would be any
better),
As Python's self-appointed spokesperson for the elderly, there's one
very clear difference: a leading "." is - literally - one microscopic
point, all but invisible. A leading caret is far easier to see, on a
variety of devices and using a variety of fonts. Indeed, I missed the
leading dot in ".x" in your email the first two times I read that
sentence.
But a caret is harder to type. So here's an off-the-wall idea: use
an ellipsis. If you're still using a maximal-munch lexer, ellipsis
followed by an identifier is currently a syntax error. "...x" is far
easier to see than ".x', easier to type than "^x", and retains the
mnemonic connection that "something is a named load pattern if and
only if it has dots".
+1 on a simple dot being hard to see.
Alternative idea: if we really ought to have a mark for references¹, why
not use the & symbol, which already signifies something like "reference"
in C(++) and Rust?
¹: I know marking "store" instead of "load" has been suggested before;
I'm still on the fence on which I prefer but I would even accept marking
both (with = and == respectively, for example).
_______________________________________________
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/YH3SXITYAAPEVD4RKH6OPSWWJZEHGGC3/
Code of Conduct: http://python.org/psf/codeofconduct/
