On Fri, 10 Jul 2020 at 10:33, Glenn Linderman <v+pyt...@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-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/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
_______________________________________________
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/XLCSWQDJKZNSBO3PTRPBNBLUYEUFULP7/
Code of Conduct: http://python.org/psf/codeofconduct/
