Hello,

On Thu, 12 Nov 2020 09:55:10 -0800
Guido van Rossum <gu...@python.org> wrote:

> The position of PEP 622/634/535/636 authors is clear: we see this as a
> necessary feature to support using enums (e.g. Color.RED) or constants
> defined in other modules (e.g. re.I) when simple switch functionality
> is being migrated from literals (e.g. case 404) to named constants
> (e.g. case HTTPStatus.NOT_FOUND). Bothering users with the
> technicality of needing to use '==' here is a big usability hit.

As was pointed out many times on the mailing list, there's a very
obvious way around needing to use '==' there. It's explicitly marking
capturing terms in case's:

match foo:
    case ("foo", >val1):
        ...
    case ("bar", >val2):
        ...

Besides solving the chore of needing "==" prefix, it allows for
the following benefits:

1. Much more intuitive for beginners. (If Python adopts it, I see
other "user-friendly" languages adopting the same pattern in the
coming decades).

2. Upholds the rights of people who see "match" as glorified "switch"
statement, and not keen on it doing assignments behind their backs. (The
topic which was recently mentioned on the list.)

3. Solves discrepancy with cases like:

# Why is this possible?
obj.foo, obj.bar = val

# And this is not?
match val:
    case obj.foo, obj.bar:
        
4. Most uses of pattern matching known to people ("mental background")
are from languages with strong culture of immutability. And that's why
those languages manage to do it without much of sigils. For a language
with a looming conceptual debt of not having constness/immutability in
the core language semantics (aka, "Please move this subtopic to a
subject that doesn’t have “PEP 622” in its topic."
"https://mail.python.org/archives/list/python-dev@python.org/message/GFMOZ6XFIJKQ4ST7TFTCMRUGICZASE5G/
 ),
the idea to mark capturing terms, seems like a very smart way to route
around this conceptual deficiency, yet improve readability.


pp.3 and 4 also explain why it's

obj.foo, obj.bar = val

but would be:

match val:
    case >obj.foo, >obj.bar:

With destructuring assignment, the *assignment* operator is right
there, and terms are on the left side of it, so it's all clear to
a reader.

With "match", there's no obvious assignment operator, and terms can be
also used as values, so adding explicit "assign here" marker looks like
rather natural idea to keep a reader in loop of what's happening there.


[]


-- 
Best regards,
 Paul                          mailto:pmis...@gmail.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/WEDBWEFGFL4VLNWP6V63RJ7TM4OKRIII/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to