On 7/10/2020 3:15 AM, Gustavo Carneiro wrote:
On Fri, 10 Jul 2020 at 10:33, Glenn Linderman <v+pyt...@g.nevcal.com
<mailto:v%2bpyt...@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.
Actually, the current if elseif elseif elseif else, used now because
Python has no switch/match/case, has exactly the same issue as you
describe as a problem with try if there were more cases... and if often
has more cases, just like match will.
So your concern seems nebulous. You may have wished for extra
indentation.... but it is simple to get more indentation: use 8 spaces
instead of 4. So if you really wanted it, you could have had it. It is
much harder to get less indentation when the language structures
prescribe it.
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
<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-le...@python.org
<mailto: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/NHNEQ5MLZQITL5F3IDHPD3XSSHCJDSAP/
Code of Conduct: http://python.org/psf/codeofconduct/
