Precisely, and this is what I meant when I talked about implementing Rust results in Python. In Rust, there is language and stdlib level support for reducing that boilerplate, and for making the job of handling error values comfortable. That language-level support isn’t there in Python, so returning exception values is just annoying and clumsy.
And for what it’s worth, very few non-beginner Rust programs match on error values either. Most real-world programs use higher-level features to handle error processing.
well we’re not talking about implementing a new ? operator right out of the gate for example, just a small change to how match handles exception objects. IMO it doesn’t seem unreasonable, your opinions on what constitutes “annoying and clumsy” aside.
And for what it’s worth, the current state of SPM on Exception objects is more annoying and clumsy, so not sure as to if this is a reasonable objection to begin with.
we’re talking about going from this:
match ValueError("error"):
case ValueError(args=(str as msg, )):
print(msg)
to this
match ValueError("error"):
case ValueError(str as msg):
print(msg)
Finally, Python is multiparadigm; we’re not talking about bricking two-track exception handling in favor of single-track here.