RFC: refactor geometry matching clauses with Python 3.10's pattern matching

[neutrinoceros]

PR Summary

Now that we don't support 3.9 anymore we have access to match/case statements (pattern matching). Arguably this improves readability in these instances, albeit at the cost of an additional indentation level.

[matthewturk]

Oh, I like this a lot more. Thank you.

Quick question -- is there something about the way the | is evaluated in the cases that means it has to be put in the case? Or, could we create top-level special cases like HAS_Z_AXIS for CARTESIAN | POLAR | SPECTRAL_CUBE ?

[neutrinoceros]

is there something about the way the | is evaluated in the cases that means it has to be put in the case?

If you're asking if | has a syntactically different meaning in the context of case clauses, the answer is yes.
See https://peps.python.org/pep-0636/#or-patterns

could we create top-level special cases like HAS_Z_AXIS for CARTESIAN | POLAR | SPECTRAL_CUBE ?

I think this would be achievable using IntFlag enums, however we need geometry to be an StrEnum for backward compatibility, and I don't fancy trying to implement a common subclass.

[matthewturk]

I think this would be achievable using IntFlag enums, however we need geometry to be an StrEnum for backward compatibility, and I don't fancy trying to implement a common subclass.

Me neither! I think the first answer, that | is syntactically different, is enough to say this is perfect as-is. Thank you!

[neutrinoceros]

I want to push couple times to this branch before I can undraft this.

[chrishavlin]

ok, i'm now convinced of match/case's usefulness :) I was kinda ambivalent about it before.

[neutrinoceros]

I'll merge now to save myself some conflict solving later.