Ivan Levkivskyi

Since now `get_origin()` is moved to `typing`, I think the best way to do this is just to have a global mapping. Potentially, we can even add a flag to...

(I will not have time to work on this any time soon, but PRs are wellcome :-))

On one hand, there is a plan to add some extra functionality to `typing_inspect` (see #31), I could imagine some kind of helper like this can be added there. On...

Just for fun here is a possible implementation of `InRange(x, y)`: ```python class InRange: @staticmethod def __match__(obj): if isinstance(obj, (int, float)): return MatchWrapper(low=DummyLow(obj), high=DummyHigh(obj)) class DummyLow: def __init__(self, value): self.value...

> I am not so keen on such magic objects any more. [...] But +1 on a module with helpers like MatchWrapper. OK, I agree.

In my notes I require `**rest` for a match to succeed, but I agree that actually mappings are different from sequences: they have "structural subtyping" behavior, i.e. passing a dictionary...

> I think @ilevkivskyi probably meant the latter Yes. But I am also fine with dropping this. Initial motivation was some symmetry with sequence/mapping pattern, but since we are not...

FWIW, impossibility to use `list[int]` is the main reason why I don't like the annotation syntax.

It is interesting that I see choice aspect more important than assignment aspect (as I mentioned in other issue), yet `as` still sounds better to me. Maybe this is personal,...

I think Guido convinced me that use cases where current proposal doesn't work (i.e. requires "trivial" guarded matches like `x if re.match("[0-9]*", x)` or `x if 1