I always liked how this automatically hooks into the python installation via pip, but preferred another text format. Hm. So if you want to permanently replace python's crash message, you could put a file `sitecustomize.py` into your python path, with these contents for example:
# in site-packages/sitecustomize.py:
print('hello!')
import sys; sys.excepthook = lambda a,b,c: print('<bomb emoji>')
# or also:
import stackprinter
stackprinter.set_excepthook(style='darkbg')
(you can find the path by `python -c "import site; print(site.PREFIXES)" `)
It felt bit much to do that automatically on installation, but maybe it would be a good option to have
In case you're looking for opinions there: I pretty much like libraries like this for development but prefer manual activation, e.g. only when my system is running with a debug flag, over libraries messing with the environment itself.
Thanks for making it available, the output looks neat, looking forward to try it out.
One situation where I would have wanted a real debugger and couldn't use one was in crash reporting on remote systems (like, machine learning code running in some container somewhere, or on a headless box far from the network).
Since Python's built-in tracebacks are pretty minimal, the default crash logs don't offer much help other than a line number. I ended up writing a tool that prints tracebacks along with code context and local variables [i], sort of a souped up version of the built-in crash message. It's surprising how much that already helped in a few situations, makes me wonder why it isn't the default.
So, yes, more debuggers, but also abundant logging everywhere!
a) Crashes dump the program state to a file and then you load that in the debugger.
b) If the process is still running but broken, attach the debugger.
c) In my firmware I log bus fault addresses and restart. That allows me to see what code or memory access caused the error. 75% of the time it's fairly obvious what happened.
Crash dump debugging is tricky to implement Python, because its normal debugging APIs - sys.settrace, frame objects etc - require being inside the process with a running Python interpreter.
You can still do it, but you basically have to redo the whole thing from scratch. For example, instead of asking for a repr() of an object to display its value, you have to access the internal representation of it directly - and then accommodate all the differences in that between various Python versions. Something like this (note several different dicts): https://github.com/Microsoft/PTVS/tree/bcdfec4f211488e373fa2...
Python's standard lib has had something like this for years, but it's been criminally under-promoted (probably because of the terrible name): https://docs.python.org/3/library/cgitb.html
However, yours provides much nicer output. Thank you!
By pure chance I know one exception to this ad-tech/e-commerce bias in Berlin: I'm at a Berlin-based company[0] working on DL and deep RL for industrial applications (think robots, optimisation and control).
That's way cool. I'm a cybernetics graduate, and I've long thought that the current ways of regulating processes could probably be improved upon with ML. Tough to get any one to pay attention because PID is usually good enough, and the field generally value mathematical analyzability, which ANNs are not particularly known for.
https://news.ycombinator.com/item?id=19717786
https://news.ycombinator.com/item?id=19772902