> try catch is different keywords from virtually all other languages

Python : try/catch/finally/else

C# : try/catch/finally (no equivalent of “else”)

VB.net : try/catch/finally (no equivalent of “else”)

JavaScript : try/catch/finally (no equivalent of “else”)

Java : try/catch/finally (no equivalent of “else”)

Ruby: begin/rescue/ensure (no equivalent of “else”)

C++: try/catch (no equivalent of “finally” or “else”)

Python’s try/catch/finally/else seem to use exactly the same keywords as many other popular languages (Ruby is an oddball here, using similar semantics with different keywords), except that “else” is a unique feature, and C++ lacks “finally”.

Python is try/except, not try/catch. I don't think it matters in the least that it's different, but it is different.

Python uses try/except and instead of throw uses raise.

Ruby does have a good reason to be oddball IMO. begin isn't always required. When inside a method, module, class, or do...end block definition (read: most of the time), you're able to use the rescue keyword solo. Anything raising an exception in the method above the rescue keyword will be caught.

It can also be used postfixed to a statement that might raise an exception.

Ruby is oddball here because it's subtly different.

  def a_method
     @value = dangerous_method_call rescue "default value in case of exception"
     do_something_else @value
  rescue
     puts "an error, oh no"
  end

> typing is awful, unsound in a lot of cases

tl;dr:

1. This is my biggest issue with Python.

2. Are there any tolerable solutions you've found?

3. Are there any non-Python languages you'd recommend?

The root of Python's typing issues seems to be ad-hoc syntax recycling as a stand-in for a thoroughly planned type system. Understandably, Guido and others advise using Protocol types to make up for earlier design decisions. It sort of works, but:

1. It's effectively an unspoken deprecation for parts of the standard library

2. Current design choices create new problems

3. It still doesn't reliably prevent runtime errors

Things break down further as you move beyond the built-ins:

1. Pydantic and other tools come with their own problems

2. Ugly things happen at boundary lines in APIs (ctypes vs OOP)

3. All of these get even worse as Sphinx gets involved

The last two items came up in a recent PR discussion. The other commenter's point seemed correct: simple, specific, and rigid types prevent problems. But then why should we have Generic and Union at all?

I'm still going to use Python when necessary, but it makes the grass look very green near languages like OCaml and Elm. If Rider can make .NET's packaging tolerable, maybe F# would be good too. Are there any others you'd suggest?