3 ms·
Say you're given a Python function in a large codebase that doesn't have documentation but does have type annotations, say, to indicate it returns Optional[str]
by btown 5y ago
Say you're given a Python function in a large codebase that doesn't have documentation but does have type annotations, say, to indicate it returns Optional[str]. Does this tell you that you just need to check for None, and otherwise it's a string?
Nope, it could throw. What could it throw? We don't know. There are many applications where this magnifies the dangers of any existing technical debt. One could desire strong exception-proofing of results without needing to go "all in" to a borrow-checked regime like Rust.
The Koda approach is lightweight and doesn't enforce this, but one could imagine a static checker that says "any function that returns a Result, and calls any function that does not itself return a Result or does any other risky operation, must have an exhaustive top-level try-except block, or be wrapped by a decorator that does the same."
Then, you could guarantee that all code explicitly handles exceptions, while still accessing the full Python library ecosystem - you can use non-Koda-wrapped code at any time, you just need to handle its exceptions.
Is this overkill? Possibly. But I can think of a handful of bugs offhand that this would have caught in our codebase if enforced.
- impoppy 5y agoNow this is an answer I was waiting for. Thank you for explaining the real benefits of sticking to koda style. I guess this would be obvious if I used statically typed languages since there is no try except clauses in most of them
- btown 5y agoI'll add that caveats do apply to these benefits. Many of them are outlined in https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/ https://fsharpforfunandprofit.com/posts/against-railway-orie... - which is a response to an excellent functional programming talk (see slides or video linked at https://fsharpforfunandprofit.com/rop/ https://fsharpforfunandprofit.com/rop/) that walks through why you'd want a Result-type thing to exist in the first place... and eases you into the larger world of monads!
- ReleaseCandidat 5y ago> and eases you into the larger world of monads Yes, just begin reading at page 29 https://www.slideshare.net/ScottWlaschin/railway-oriented-programming https://www.slideshare.net/ScottWlaschin/railway-oriented-pr...
- leethargo 5y agoI wanted to ask the same thing: Couldn't we just use Optional and None for this? So the point of using Koda is to communicate intent (functions that don't throw exceptions), and some utility methods?
- keithasaurus 5y agoYou can also nest `Maybe`s. Just(Just(nothing)) could convey that two levels of a computation "succeeded", but the third did not. This may not be something you see often, but it's a case that Optional can't convey. There are also cases where None is a valid value, and then Optional doesn't make sense. Maybe[None] can be a valid, if rare, use case -- Just(None) is different from Nothing. But Optional[None] doesn't make sense -- since it's None | None. You can also do other stuff with Maybe, like map, flat_map, apply. And there's more that can be added.