[Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

[Chris Angelico]

On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez <apalala at gmail.com> wrote:
> Then, if exceptions are going to be part of a type, there should be a way to express the semantics of them (like in Eiffel), so stack.pop();stack.push(x) doesn't have to catch StackFullException.
>

That assumes atomicity. If you want an atomic "replace top of stack"
that can never raise StackFullException, it's probably best to express
it as stack.replacetop(x) rather than having something that might be
interrupted.

> Newer languages like Go and Swift shy away from exceptions because of the tendency to:
>
> try:
>    # something
> except:
>      print('oops!)
>

People do dumb things with exceptions, yes. Why does this mean that
they are bad? I don't understand this. Exception handling (and stack
unwinding) gives an easy and clear way to refactor code without having
to daisychain error handling everywhere. How is throwing that away
going to help people write better code?

But then, Golang also decided that Unicode wasn't necessary, and we
should all deal with UTF-8 encoded byte sequences instead of text
strings, so I'm fairly sure there are no ten foot barge poles long
enough for me to touch it with. There are languages that have problems
because of history (*cough*JavaScript*cough*), but for a new language
to make multiple poor decisions just means it's one to avoid.

ChrisA