Introduce Result class to allow a modern representation of failure cases

[Liz (Elizabeth King)]

Please don’t a result types to the standard library as an alternative to exceptions. We don’t need another way to do things here.

If things should error, they should error. If things don’t know if they should error and have a returnable value, they should return that value or state and let the caller decide.

If things shouldn’t error, they shouldn’t error.

requests’s api is not something people should mimic. Response.raise_for_status() is horrible. requests successfully made the request, it has valid response data for you. If you decide to error, you should be doing that, not requests, and you can do it based on the value, you don’t need a result type for this.

@jcampbell05

The only way to handle this error is to understand the specific API for this bespoke Result type either by understanding what it means to be in an error and analysing those fields or using any APIs to convert this to be an exception

This means developers need to learn how to make sure they are ensuring every library they use are having their unhappy paths handled immediately when it doesn’t use exceptions

Futures and Result types don’t have this problem, the API hands you a contain object

That’s not correct. Futures and Result types without syntax support are just another return type that people have to learn.

@mikeshardmind brought this up already, and it’s hard to read your response as being in good faith.

@mikeshardmind

Without it being a language design choice where Everything that has ever and will ever exists uses this, you’re always going to need to do this. Result objects aren’t magic, and they only seem as seamless in the languages that use them consistently because of their consistent use and additional syntax/compiler features that enhance them.

“I don’t want to read the documentation for libraries I use” is not a very compelling reason.

@jcampbell05

In your opinion a “try now, catch now” approach is more desirable because it may prevent an application becoming unstable by handling errors at the immediate opportunity such as Timeout errors etc

This also appears to misrepresent someone else and directly state that someone has an opinion that hasn’t been expressed here.

@jcampbell05

And it unlocks paradigms such as the null operator where the developer doesn’t want to handle the error for accessing nested keys immediately but only when they attempt to consume it

name = object?.name
print(name.value) //“crash!”

Or an attempt to side-step reasons this was a bad idea in Introducing a Safe Navigation Operator in Python - #157 by Liz but frame it differently so that people might not see that it still has the same problems, just expressed differently