4 ms·

You can also use the breakpoint() introduced in py3.7 via PEP533 https://www.python.org/dev/peps/pep-0553/ https://www.python.org/dev/peps/pep-0553/

by est 6y ago

vonwoodson 6y ago
Bump. This is the most correct way to debug python programs VS using print statement.
- taneq 6y ago
  Debugging virtually anything real-time that interacts with other systems will require some kind of logging (of which printf() is the trivial case). Step-through debugging is great but far from universally applicable.
  - vlovich123 6y ago
    Setting a breakpoint that prints and continues is appropriate if performance doesn’t matter. It gets trickier if it does. In those cases RR seems like the best idea rather than prints. At least that’s the theory. In my experience the conditions on the ground are different though. Tooling availability is inconsistent, which is why such approaches don’t always work. Reverse debugging isn’t available on all platforms/languages. Debuggers (or at least the C/C++ ones) are slow in how they inject instrumentation code to evaluate - rather than compiling expressions into native codes to conditionally trap, they seem to trap unconditionally and evaluate the conditional using their introspection language (there are valid reasons why it’s done this way but it has serious performance impacts). In compiled languages, the evaluation of the expression can be difficult/impossible to write because of this (not enough type information available, validation is late binding meaning mistakes are extra expensive, etc. At the end of the day, when your tools fail you, print debugging is easier to use to accomplish the task rather. Getting tooling to work effectively is more time consuming and frequently not possible.
- gnulinux 6y ago
  Correct in what way? I can think of many real time systems that cannot be debugged with a pdb breakpoint.
- stjohnswarts 6y ago
  It's a way, it's hardly "the most correct way". Jeesh sometimes hackernews people. There are all kinds of ways to debug, and sometimes code has to run in different version of python. I find logging with various levels of "debug info" is best for me, but I hardly think that is "the most correct way"
- hyperbovine 6y ago
  Most correct you say? Based on what? Mind you we're talking about code that will never even ship in the vast majority of cases. Ergo, do whatever works best for you.
EamonnMR 6y ago
Pre 'breakpoint()' you could always use import pdb; pdb.set_trace() That said, sometimes you don't want to interrupt execution and see your results in real time.
- beaugunderson 6y ago
  I like `from IPython import embed; embed()` because you get an entire ipython instance with access to all local variables :)
animal_spirits 6y ago
I like to use PDB++ which is a drop in replacement for PDB https://github.com/pdbpp/pdbpp https://github.com/pdbpp/pdbpp

You can also use the breakpoint() introduced in py3.7 via PEP533 https://www.python.org/dev/peps/pep-0553/ https://www.python.org/dev/peps/pep-0553/

by est 6y ago

You can also use the breakpoint() introduced in py3.7 via PEP533 https://www.python.org/dev/peps/pep-0553/ https://www.python.org/dev/peps/pep-0553/

vonwoodson 6y ago

Bump. This is the most correct way to debug python programs VS using print statement.

taneq 6y ago
Debugging virtually anything real-time that interacts with other systems will require some kind of logging (of which printf() is the trivial case). Step-through debugging is great but far from universally applicable.
- vlovich123 6y ago
  Setting a breakpoint that prints and continues is appropriate if performance doesn’t matter. It gets trickier if it does. In those cases RR seems like the best idea rather than prints. At least that’s the theory. In my experience the conditions on the ground are different though. Tooling availability is inconsistent, which is why such approaches don’t always work. Reverse debugging isn’t available on all platforms/languages. Debuggers (or at least the C/C++ ones) are slow in how they inject instrumentation code to evaluate - rather than compiling expressions into native codes to conditionally trap, they seem to trap unconditionally and evaluate the conditional using their introspection language (there are valid reasons why it’s done this way but it has serious performance impacts). In compiled languages, the evaluation of the expression can be difficult/impossible to write because of this (not enough type information available, validation is late binding meaning mistakes are extra expensive, etc. At the end of the day, when your tools fail you, print debugging is easier to use to accomplish the task rather. Getting tooling to work effectively is more time consuming and frequently not possible.
gnulinux 6y ago
Correct in what way? I can think of many real time systems that cannot be debugged with a pdb breakpoint.
stjohnswarts 6y ago
It's a way, it's hardly "the most correct way". Jeesh sometimes hackernews people. There are all kinds of ways to debug, and sometimes code has to run in different version of python. I find logging with various levels of "debug info" is best for me, but I hardly think that is "the most correct way"
hyperbovine 6y ago
Most correct you say? Based on what? Mind you we're talking about code that will never even ship in the vast majority of cases. Ergo, do whatever works best for you.

EamonnMR 6y ago

Pre 'breakpoint()' you could always use import pdb; pdb.set_trace() That said, sometimes you don't want to interrupt execution and see your results in real time.

beaugunderson 6y ago
I like `from IPython import embed; embed()` because you get an entire ipython instance with access to all local variables :)

animal_spirits 6y ago

I like to use PDB++ which is a drop in replacement for PDB https://github.com/pdbpp/pdbpp https://github.com/pdbpp/pdbpp