That's a fair point. On some level a try block resembles a monad that encapsulates success/failure. However, it is not general, e.g. it does not provide a solution if you want to chain computations where returning None/Nothing is valid (e.g. a Map lookup in Haskell).
The nice thing about monads is that it provides an abstraction on sequences of computations, involving failure, error, state, effects, etc. Though, it can get ugly at times when you want to use multiple monads simultaneously (via monad transformers).
However, it is not general, e.g. it does not provide a solution if you want to chain computations where returning None/Nothing is valid (e.g. a Map lookup in Haskell).
But I think that's a feature, not a bug. Conflating errors and valid values leads to ambiguity. As PEP 20 says, "Explicit it better than implicit".
If you actually want certain function return values to act as a failure, I think you should wrap it in a new function that adds those semantics.
The nice thing about monads is that it provides an abstraction on sequences of computations, involving failure, error, state, effects, etc. Though, it can get ugly at times when you want to use multiple monads simultaneously (via monad transformers).