191–200 of 271 posts
Earlier quoted context omitted.
You can also use the breakpoint() introduced in py3.7 via PEP533 https://www.python.org/dev/peps/pep-0553/
Bump. This is the most correct way to debug python programs VS using print statement.
Since I became a front-end developer, all I've done is use print statements to debug JS. Feels like I've gone backwards.
Just to give credit to both “sides” in the comments here, you’re all kind of right and it’s okay if people have different workflows than you.
Newflash! You can do both, and sometimes one is better than the other.
It should take a competent programmer about 30 minutes to create a nice log class with more flexibility for their particular application. On one hand thank you for sharing, on the other hand if I add this to my project at work my boss is going to scold me
I don't do much Python, but logging is a problem that's been thoroughly solved in just about every other language I've used. Why on earth would you reach for a half baked homemade solution?
It's just depending on your application you're going to change exactly what you log, and that's where you go and put your own logic
Earlier quoted context omitted.
Which debugger would you recommend?
For Python: ipdb. In your code, you can just drop in "import ipdb; ipdb.set_trace()" and the execution will stop there with an interactive prompt. Alternatively start the script through (i)pdb and set breakpoints. You can also use plain pdb ("import pdb; pdb.set_trace()"), which has the advantage that it comes with the Python stdlib, but the interactive prompt is less fancy (no history, no autocompletion, etc).
I started writing a very-alpha related tool, https://github.com/czinck/pyset_x . As the name implies, it's like `set -x` in bash, in that it prints every line as it executes. It's more useful for situations where you have some complicated control flow and it's not working exactly how you expect.
"PySnooper is a poor man's debugger. If you've used Bash, it's like set -x for Python, except it's fancier."
Earlier quoted context omitted.
The value introduced by C++ was type safety. In C, it's way too easy for the format string to get out of sync with the type of the arguments, e.g.: printf("%d", my_long_var); Might seem correct and work correctly on one platform, but fail on another. scanf() is arguably even worse since it can cause memory corruption. These days compilers have diagnostics to catch those errors, but if you rely on those you can't use…
Maybe C++ fixed type safety, but it introduced lot of complexity and bugs for no actual added value. For instance, because of stateful ios objects, it's close to impossible to write correct code outputing hex on first attempt. I'm sure that lot of C++ code outputing hex is just plain wrong. Given that C++ keeps getting more and more complex features, it is just amazing that C++ I/O is still so inconvenient, opaque an…
std::cout