Brandt Bucher
Brandt Bucher
In short, should we be able to do simple optimizations like executing the pattern `C() | C()` as `C( | )` at runtime? Wearing my implementer hat, my answer is...
We already allow a single unary `-` for negation of numbers. Should we also allow binary `+` if the LHS is real and the RHS is imaginary, so patterns like...
Although the PEP currently defers it, I think this idea is just mature *enough* to start work on designing and testing a CPython implementation. In addition to a head start...
This is a bit pathological, but should we allow loading the name `_` in patterns? I think we should say "no", since it really has no place outside of obfuscated...
Shall we generate `__match_args__` for `typing.NamedTuple`/`collections.namedtuple`? It seems like the right thing to do if we're doing it for `dataclasses.dataclass`.
Continued from [this comment](https://github.com/brandtbucher/cpython/pull/2#discussion_r438331887), where @gvanrossum said: > I just noticed a bug (not directly related to this bit of grammar): > > ``` > >>> match "abc": > ......
`**_` in a mapping pattern and `_ :=` in a named pattern don't seem like they could ever make sense. I think we should be consistent, and *always* ignore stores...
It is useful to be able to match against both the type *and* the value of a target. Currently, the only way to do this is to manually assign `self`...
We may be able to make more powerful optimizations possible in the future if we clearly and explicitly state that there are no guarantees as to the order (or number...
@brandtbucher: > ...one could write `from (x):` if there are no captures, or `from (x) -> (y, z):` to have every occurrence of `y` or `z` in a match be...