pytest also has helpful tracebacks; though only for test runs.
With nose-progressive, you can specify --progressive-editor or update the .noserc so that traceback filepaths are prefixed with your preferred editor command.
vim-unstack parses paths from stack traces / tracebacks (for a number of languages including Python) and opens each in a split at that line number.
https://github.com/mattboehm/vim-unstack
Here's the Python regex from my hackish pytb2paths.sh script:
'\s+File "(?P<file>.*)", line (?P<lineno>\d+), in (?P<modulestr>.*)$'
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.
If you're building a server application, you should be aware of the kinds of information you're writing to your application log. The first obvious issue is that of possibly disclosing information if the traceback is returned to the client instead of saved in the server log. The second, less obvious question is what kinds of statutory requirements you are under regarding retention of PII in your logs. And in the worst case scenario, you could end up writing out things like plaintext passwords and unrelated PII from the environment.
I bring this up because this looks like it discloses variable values into the log that would not be printed in a standard traceback under most normal circumstances.
+1 to this. We have some middleware that scrubs our database exceptions for precisely this reason. You need to think about this any time you're logging the value of any variable, if your company handles any PII or other sensitive information whatsoever.
While this is a cool project I kinda wondering if they tried submitting a PIP. I think such debugging enhancements to Cpython would be great. Is Python communities considering any improvements on traceback information?
I assume you mean PEP (Python Enhancement Proposal) :)
A PEP has a lot more to consider than a standalone, third-party projects. They also need to support most (of not all) usages of Python, which is extremely involved. E.g. zip import might be a problem, from the top of my head.
It is always worth considering proposing a PEP, of course. But don’t expect people to have interests in proposing, or (if they do propose) the proposal to get anywhere without significant efforts (and compromises).
12 comments
[ 3.1 ms ] story [ 35.7 ms ] threadWith nose-progressive, you can specify --progressive-editor or update the .noserc so that traceback filepaths are prefixed with your preferred editor command.
vim-unstack parses paths from stack traces / tracebacks (for a number of languages including Python) and opens each in a split at that line number. https://github.com/mattboehm/vim-unstack
Here's the Python regex from my hackish pytb2paths.sh script:
https://github.com/westurner/dotfiles/blob/develop/scripts/p...It felt bit much to do that automatically on installation, but maybe it would be a good option to have
Thanks for making it available, the output looks neat, looking forward to try it out.
well, not me anyway
I bring this up because this looks like it discloses variable values into the log that would not be printed in a standard traceback under most normal circumstances.
A PEP has a lot more to consider than a standalone, third-party projects. They also need to support most (of not all) usages of Python, which is extremely involved. E.g. zip import might be a problem, from the top of my head.
It is always worth considering proposing a PEP, of course. But don’t expect people to have interests in proposing, or (if they do propose) the proposal to get anywhere without significant efforts (and compromises).