On Fri, 10 Jul 2020 at 10:33, Glenn Linderman <v+python@g.nevcal.com> wrote:
On 7/10/2020 1:21 AM, Stefano Borini wrote:
> Just my 2 cents, I find it kind of annoying that the whole structure
> requires two levels of indentation to actually reach the operational
> code.
> This would be a first in python.
>
> I would prefer an option akin to if elif elif else where each block is
> only one level deep.
Me too.

That would also sidestep the dilemma of whether else: (if implemented)
should be indented like case: or like match: because they would be the same.

match:
     t
case ("rect", real, imag):
     return complex(real, imag)
case ("polar", r, phi):
     return complex( r* cos(phi), r*sin(phi)
else:
     return None

but it does make the match: block not a statement group, which was
disturbing to some.

On the other hand, this has a correspondence to:

try:
      throw expression
except (type of expression) as exc1:
      blah blah1
except (another type) as exc2:
     blah blah2
else:
     blah blah3

The problem of the try...except structure, with less indentation, is that, yes, it is OK for exceptions because normally you have 2 or 3 `except XXX` clauses, therefore it is usually easy to follow, if the number of vertical lines in the entire block of try-catch is low enough.

But I have had cases with catching many exception types, each with its own block of 4 or 5 lines, adding up to a block of try-excepts that doesn't even fit in a single window of my editor.  In that case, I always have wished for except clauses to be extra indented, to more easily distinguish where the try..except block ends.

Therefore, I posit that the style of try...except indentation only works where the number of cases is small.

But for the case of pattern matching, I expect the number of cases to be matched to be a lot higher than exception handling cases.  Having cases to be matched be indented is, IMHO, a nice visual cue to help the reader understand where the pattern matching block ends.
 
In fact, one _could_ wrap this whole feature into the try: syntax... the
match statement would be tried, and the cases would be special types of
exception handlers:

try:
     match expression
case ("rect", real, imag):
     return complex(real, imag)
case ("polar", r, phi):
     return complex( r* cos(phi), r*sin(phi)
else:
     return None

If the expression could fail to be calculated, one could have a mix of
except clauses also to catch those, rather than needing to wrap the
whole match expression in a separate try to handle that case [making the
nesting even deeper :( ]

There might even be a use for using case clauses to extend "normal"
exception handling, where the exception object could be tested for its
content as well as its class to have different handling.

try:
     raise Exception("msg", 35, things)
case Exception( x, "widgets"):
     blah blah 1
case Exception( x, "characters"):
     blah blah 2
else:
     blah blah 3

In this not-fully-thought-through scenario, maybe the keyword match
isn't even needed: "raise expression" could do the job, or they could be
aliases to signify intent.

In other words, a match expression would always "fail". The only
mismatch here is that it points out the difference between try-else and
match-else: try-else is executed if there is no failure, but if match
always fails, else would never be appropriate, and case _: would be.

In any case, it does seem there is a strong correlation between match
processing and try processing, that I didn't see during other
discussions of the possible structural similarities. "match 3 / 0:"
would clearly need to be wrapped in a try:

try:
     match x / y:
          case 43:
                print("wow, it is 43")
          case 22:
                print("22 seemed less likely than 43 for some reason")
         case _:
               print("You get what you get")
except ZeroDivisionError as exc:
     print(f"But sometimes you get an exception {exc}")

or:

try:
     raise x / y
case 43:
     print("wow, it is 43")
case 22:
     print("22 seemed less likely than 43 for some reason")
case exc := ZeroDivisionError:
     print(f"But sometimes you get an exception: {exc}")
case _:
     print("You get what you get")
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/GDP2KKB3SUWQZRSNTR5N36LXZ6HDS2QL/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert