5 ms·
Oh, yikes. I understand what's happening here but this is going to bite a lot of people. I might be misreading the grammar but it looks like you can produce th
by utborin 6y ago
Oh, yikes. I understand what's happening here but this is going to bite a lot of people.
I might be misreading the grammar but it looks like you can produce the desired effect by using an attribute, e.g. the following would perform an equality check, not an assignment:
match status:
case requests.codes.not_found:
return "Not found"
The tutorial seems to confirm this: "This will work with any dotted name (like math.pi). However an unqualified name (i.e. a bare name with no dots) will be always interpreted as a capture pattern"
- deleted 6y ago[deleted]
- TrianguloY 6y agoYes, apparently your example will work correctly. Now think what will happen if you need to move that not_found variable to the same file as that code (so it will no longer be a dotted name). If you do it manually you need to be extra careful, if you use an automatic tool either it will reject the change or will need to create a dummy class or something in the process.
- im3w1l 6y agoThe inconsistency just makes it worse and will lead to even more bugs. I foresee lint rules prohibiting match statements in the near future.
- coldtea 6y agoCouldn't they have used "case" and "capture" clauses instead? match status: case not_found: return "Not found" capture success_code: return "Returned success code: %s" % success_code or the "_ as x" or a myriad other ways to make capture explicit...
- ben509 6y agoA separate statement doesn't compose with complex patterns. I'd prefer always requiring the walrus operator to capture: match response: case (not_found, msg := _): return f"Not found: {msg}" case (error, "No swizzle available"): return "We lack swizzle. :-(" case pair := (_, "Swizzle"): log(f"Unexpected swizzle: {pair}") return f"Swizzle?" case ((code := _), _): return f"Success: {code}"