On 24.06.2020 20:08, Guido van Rossum wrote:
On Wed, Jun 24, 2020 at 7:27 AM M.-A. Lemburg <mal@egenix.com <mailto:mal@egenix.com>> wrote:
Wow, so 19 years after PEP 275, we are indeed getting a switch statement. Nice :-)
Indeed. Fortunately there are now some better ideas to steal from other languages than C's switch. :-)
Your PEP certainly is a lot more powerful than the good ol' C switch :-) Something I know the Perl camp is always very fond of is the matching on regexps. Is this possible using the proposal (sorry, I don't quite understand the __match__() protocol yet) ?
Something which struck me as odd when first scanning through the PEP is the default case compared to other Python block statements:
match something: case 0 | 1 | 2: print("Small number") case [] | [_]: print("A short sequence") case str() | bytes(): print("Something string-like") case _: print("Something else")
rather than what a Pythonista would probably expect:
match something: case 0 | 1 | 2: print("Small number") case [] | [_]: print("A short sequence") case str() | bytes(): print("Something string-like") else: print("Something else")
Was there a reason for using a special value "_" as match-all value ? I couldn't find any explanation for this in the PEP.
Nearly every other language whose pattern matching syntax we've examined uses _ as the wildcard.
The authors don't feel very strongly about whether to use `else:` or `case _:`. The latter would be possible even if we added an explicit `else` clause, and we like TOOWTDI. But it's clear that a lot of people *expect* to see `else`, and maybe seeing `case _:` is not the best introduction to wildcards for people who haven't seen a match statement before.
A wrinkle with `else` is that some of the authors would prefer to see it aligned with `match` rather than with the list of cases, but for others it feels like a degenerate case and should be aligned with those. (I'm in the latter camp.)
There still is a lively internal discussion going on, and we'll get back here when we have a shared opinion.
Great. Thanks for considering it. I'd make "else" match its use in other statements, which would mean aligning it with "match", but don't really feel strong about either way. The problem I see with "case _" is that it's just too easy to miss when looking at the body of "match", even more so, since people will not necessarily put it at the end, or add it as or'ed add-on to some other case, e.g. match something: case 0 | 1 | 2 | _: print("Small number or something else") case [] | [_]: print("A short sequence") case _: print("Not sure what this is") case str() | bytes(): print("Something string-like") You could even declare the above stand-alone or or'ed use of "_" illegal and force use of "else" instead to push for TOOWTDI. Oh, and thanks for not having continue / break in the switch cases ! Those tend to often cause subtle bugs in C applications (ie. a missing break). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jun 24 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/