101–110 of 149 posts
It misses the most important one-liner for python debugging: import pdb; pdb.set_trace() which leaves you in the debugger at a specific point in your code. When I actually did Python dev rare was the day I didn't crack that out!
breakpoint()Nice article. In particular the -i flag seems really useful. I'd like to add two packages I learned about recently that I like A LOT: pyrasite and PySnooper. Use pyrasite to "attach" to an existing running Python process (i.e. you forgot to instrument the app, but it has a bug in it, how can you debug?) (1) Install pyrasite (2) Get the PID of the running process (3) Run `pyrasite dumpstackz0.py` where dumpstackz0.pyc…
This is a bit of a weird article. It spends most of the time talking about logging, which is somewhat useful for debugging but not really. pdb gets a few lines of description, and that is about it. Personally, I can't live without Pycharm when working with Python purely because of how fantastic the debugging experience is. The integration with the interactive IPython shell is simply fantastic, and the live variable v…
I've been using the Wing IDE for several years. It sometimes chokes when I try to inspect larger numpy arrays as a whole, using the application-specific array visualization (but there are other ways). Otherwise I'm quite happy with it.
Earlier quoted context omitted.
Anecdotal, but I have never seen any of my colleagues with PyCharm work more quickly than me in Sublime Text. I think if you "struggle" in an IDE or editor, it's not really the IDE or editor that's the problem. A "jump to definiton" key and plaintext search tools (I use grep or ag in the command line) tend to be enough for me 99% of the time. I also think there's something to it being forced to think about your code…
I work with data scientists and ML people more than hardcore developers, but I've noticed that a lot of people who use sublime text tend to resort to print() debugging. IMO python's lack of explicit typing makes it difficult to reason about by inspection alone ("does foo() return a dataframe or a numpy array?!"). For me at least, I need to get into the guts of a system and watch it execute to really understand it. Th…
I do tend to reach for a simple log first though. I find it's ofte quicker to place a bunch of log statments than step through every statment. The debugger comes out for more complex issues.
Earlier quoted context omitted.
I second PyCharm, not only from a debugging perspective but as a whole. I don't understand people struggling with generic text editors, development oriented text tools (sublime etc), or even vscode just because they are free when there is a much better tool money can buy (and PyCharm has a free, community version as well).
VSCode and Visual Studio have first class support for Python. https://visualstudio.microsoft.com/vs/features/python/ https://code.visualstudio.com/docs/python/python-tutorial Both include quite capable debuggers, and AI powered code completion, intelicode. https://marketplace.visualstudio.com/items?itemName=VisualSt...
Early on I used Eclipse plugin for similar reasons - unified debugging across multiple platforms.
I'm somewhat embarrassed to say that I very rarely use debuggers. Print statements have always worked for me even in large codebases. What am I missing here?
I'm the opposite - immediately run in the debugger to probe around how to use this or that API or verify that the code is really doing what I think. I also find that stepping through my code early on often gives me insight in how to implement something more efficiently.