[prirun]

the amount of work they do -- and the code produced, and thus the work reviewers have to do -- should be proportionate to how unusual the necessary error handling is.

Great comment. I would add how unusual _and critical_.

One of the things I love about Python is that while I know errors can occur on practically every statement written, I only have to add error handling for likely / expected / critical errors. Any unlikely errors that occur, even in production, will show a detailed stack trace (lots of context), making them easy to fix.

In my experience, things work as expected 98% of the time. For some software, like a pacemaker, checking the execution of every single line of code and even having redundant error checking is not overkill. For other software, like the backup software I work on, having one customer out of 1000 get a weird error is something I'd rather deal with as a support ticket rather than having to anticipate it while writing code.

Of course error handling is important, but requiring 3 lines of error handling for every 1 line of actual code has kept me from investigating Go to replace Python for HashBackup. I'd love to get the performance increase, but not for a 4x expansion of LOC.

[OvermindDL1]

Honestly when I look to rewriting a python thing to be 'faster' either try using PyPy first, or rewrite it in OCaml instead. OCaml is extremely simple, similar to python in a lot of ways (GIL and all), but runs at native code speeds, near C the majority of the work, and super easy to bind to C libraries if you need.

Or try Rust. ^.^