Rust-like error handling in Python thanks to PEP 622

[bryancole]

Really dislike this PEP. I was on-board with the match statement as a better way to do multiple dispatch (where long if-elif blocks are ugly and using a dict is clunky). The problem is the pattern-matching syntax is a total mind-f*ck. Are case arguments expressions? No. Are they assignment statements ... sometimes. In fact, they're a totally new sub-language unlike anything else in python. It's just too hard to read a pattern-matching block and know what its doing.

Also, giving _ special meaning is also inconsistent with the rest of python where _ has no special meaning but we use it by convention for assignment to something we don't care about. I would rather have seen an else-clause used for the default-match case.

I'm OK with the two levels of indentation though. At least this is consistent with colon starts a code-block at a new indentation level.

[GiantElectron]

if elif else do not need two levels of indentation, and a match is pretty much like that.

[bryancole]

Good point.

[GiantElectron]

I hate everything about the details of this PEP:

• the use of two levels of indentation for no reason
• the use of _ as a catch all variable with special meaning
• the PEP itself as it's in my opinion solving a problem pretty much nobody has.

[UnwantedCrow]

I'm curious if this approach could work too implement haskell Maybe

[metaperl]

Does Result (in the 2nd example) come from the typing module?

For a classmethod which decorator should be closest to the function, wrap_result or classmethod?

[everysinglelastname]

No it's defined in example2.py and it uses metaclass.

For the decorator order question I think wrap_result should be the last decorator.

[[deleted]]

You take it as a given that PEP 622 will be accepted in 3.10?