Sascha Desch

@gvanrossum > The main use case is definitely FP style structure unpacking. **An early proposal didn’t even _have_ constant value patterns**. But named constants and enums are very much part...

> Given typical usage I still want to use unadorned names for capture variables. Maybe we can introduce some notation that allows _any_ expression to be used as a value?...

> @SaschaSchlemmer that has the same problem I identified above: it's very easy to just write `case DEBUG:` and have a hard-to-detect bug. That case can be made for any...

@natelust > Im not sure to which part you are giving the thumbs down to, you prefer the spelling in the current proposal and implementation? I personally find it more...

@natelust > ```python > def getRadius(obj, reference_frame): > # only match objects that were created in a given reference frame > match obj: > case Point(x, y, z, reference_frame=.reference_frame): >...

I hope it won't be held against me when I throw (yet another) new idea into the ring at this stage. We all agree that the major issue of the...

@Tobias-Kohn You summarized my train of though pretty well (although I didn't explicitly think about the 1. level since this use case is already covered pretty well by `if ......

@Tobias-Kohn I meant that the two-way door is that we could introduce match and a case clause with store semantics now and decide later whether we'd like load semantics at...

@Tobias-Kohn to be honest I have not seen a convincing example where I'd prefer load semantics (except for literal values) over using store semantics and an appropriate guard.

Another example might be merging of two nested dicts for which there are a ton of super ugly (and most probably subtly buggy solutions on [stackoverflow](https://stackoverflow.com/questions/7204805/how-to-merge-dictionaries-of-dictionaries/)) In my own [answer](https://stackoverflow.com/questions/7204805/how-to-merge-dictionaries-of-dictionaries/49813648#49813648)...