On 24.06.2020 20:08, Guido van Rossum wrote:
> On Wed, Jun 24, 2020 at 7:27 AM M.-A. Lemburg <m...@egenix.com
> <mailto:m...@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/
_______________________________________________
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/UABXTHJR6O3PB4ARF5QDLBQYXZ2PA3QL/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to