Printstack – Python package that adds stack trace links to the print function | Hacker News Reader

Printstack – Python package that adds stack trace links to the print function

github.com

57 pointsmfgs17 comments

I wonder, when you already run this within PyCharm, why not just set breakpoints and use the PyCharm debugger?

For unhandled exceptions, I have also my own little package: https://github.com/albertz/py_better_exchook

I sometimes also wrap this like:

    try:
        # Sth which might throw whatever,
        # but we could still proceed afterwards with reasonable
        # fallback logic, or just skip this.
        ...
    except Exception:
        print("Warning: XY failed...")
        # print stack trace, but then proceed
        sys.excepthook(*sys.exc_info())

> I wonder, when you already run this within PyCharm, why not just set breakpoints and use the PyCharm debugger?

It's not just PyCharm. A debugger can be set up in many other development environments, but it seems some people refuse to use a debugger. I've seen this more in the PHP community, where people swear that they'll never use a debugger and say there's no need to learn because putting `var_dump` everywhere is better.

For sure, packages like these have their places, but if you're using it for debugging, you're doing software development wrong.

I can sympathize, though, with situations like trying to use a remote debugger when there's a distributed backend of php services. In that case, your var_dump gets distributed everywhere too, so you don't need to chase where the request went to.

For me, unit tests is what's replaced the debugger.

I still try to fire up the PyCharm debugger sometimes, but setting up the environment usually proves too hard.

For try excerpt scenario yoi described the Logging.exception method is my favorite way to print the traces: https://docs.python.org/3/library/logging.html#logging.Logge.... Using that you don’t have to catch any particular exception and the trace will be output everywhere you have a logging handler configured.

Heh I just wrote the same thing for JS the other day: https://gist.github.com/pirate/b190ece7fd3715653147400025d22...

Helps so much when trying to track down random unhandled promise rejection / async errors that don't always execute linearly with the rest of the program flow.

In my company this was done rather less hacky-ly in PHP: the logger accepted an exception and printed its backtrace. Stray exceptions are captured at the top. ‘Idea’ IDEs already recognize paths like ‘/dev/printstack/examples/example.py:3’ and link them straight to the line. In the web logger interface, that was linked to the web git interface (in theory could be linked to a custom desktop protocol though). In the terminal, e.g. iTerm can process various formats on hover and link to apps or custom protocols.

Custom protocols are generally an okayish glue between the browser and other apps, e.g. you can add notes to Org-mode or call other Emacs functions. And the protocols also work from other apps, of course—like Alfred.

Nice and simple - thanks :)

I wrote a log function for debugging which does something similar for my own projects, but this is even easier to implement, and provides superior output.

Thanks for this - I'm guilty of using prints when I'm debugging airflow scripts since I can't execute + debug locally.

This could be very useful when trying to track down annoying logging noise.

Surely a grep -rin ./*.py would suffice

Could you add a LICENSE?

Done.

Pro tip: Don't use print functions/statements.

This could be used to track down noisy prints in an existing codebase though.

Real pro tip: don't listen to newbies that don't know yet the power and efficiency of print based debugging!

Reply on news.ycombinator.com