If you’re not using an IDE, then I’d highly recommend trying PuDB: https://github.com/inducer/pudb/blob/master/README.rst
Guide to Python Debugging
111–120 of 149 posts
Re: Guide to Python Debugging
#112This 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'm curious - how do you use pdb when debugging, say, controllers on web functions? I guess you can try and debug underlying functions using pdb, but i'm not sure how it happens (short of logging) once you're means of interaction is an HTTP call, or a response (e.g., to a trigger/message)
Run the application locally in a terminal and just use pdb normally. To do it to an application running in a container is slightly more involved but still possible.
Re: Guide to Python Debugging
#113Earlier quoted context omitted.
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…
Can you recommend anything to learn debugging the proper way (or maybe the article here is a good resource)? I might be one of these print() people- usually when I hit bugs I read through the stack trace and can figure it out, but if it's more of an "unexpected result" I resort to print() so I know exactly what I'm doing. Would love to learn a more efficient way
Andreas Zeller’s Software Debugging course on Udacity is excellent and also free: https://www.udacity.com/course/software-debugging--cs259
Re: Guide to Python Debugging
#114This 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…
There is a divide: Some people love debuggers, some people think placing print statements is the best way to debug code. You are reading an article from the second camp. Log files have the benefit of being able to adjust the signal-to-noise afterwards, I guess that is why it is highlighted.
I was impressed that almost everyone in the book Programmers at Work used print statements to debug. It changed my mind about using it for debugging code.
The book: https://www.goodreads.com/book/show/2092682.Programmers_at_W...
I have a newer edition, but I'm not at home now.
Re: Guide to Python Debugging
#115Earlier quoted context omitted.
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...
I've tried it, and watched many a colleague "struggle" with it. "First class" is definitely an over-statement from my perspective, even if it might be great compared to what you'd get with plain-text editors. It's type-hinting half the time behaves oddly even with type-hinting present. But it is getting better, that's for sure. Looking forward to see upcoming iterations.
My "first class" remark is because it comes from Microsoft itself and isn't a third party plugin.
Re: Guide to Python Debugging
#116I have a complete off the topic question, how do I create a slick blog like this - simple and minimal?
Re: Guide to Python Debugging
#117I have a complete off the topic question, how do I create a slick blog like this - simple and minimal?
The writer has his blog sourcecode on Github.
https://github.com/MartinHeinz/blog-backend
The frontend is built on Vue.js.
Re: Guide to Python Debugging
#118Earlier quoted context omitted.
I write Python with an enhanced text editor every day and don't struggle in the slightest. It's lightening quick as well. I pull out a proper debugger about twice a year.
What are you working on that you never need to pull out a debugger?
I almost always understand my code, maybe I’m good at it, not sure. I use a lot of logging and untangle tech debt at first opportunity.
That said, it isn’t rocket surgery. ETL, web services, and FS/image tools lately.
Re: Guide to Python Debugging
#119This 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…
There is a divide: Some people love debuggers, some people think placing print statements is the best way to debug code. You are reading an article from the second camp. Log files have the benefit of being able to adjust the signal-to-noise afterwards, I guess that is why it is highlighted.
There really is no logical argument. People have their preferences for a bike or a car but the car is faster than the bike just like how the debugger is generally better then printing. There is very little logical argument for the alternative.
Taking a snapshot of program state using log is isomorphic to freezing the program at that same state. The difference is that with the debugger you have the option to step into the next state or increase your resolution and look at state within a lower level module/function. With the debugger you have access to ALL state at the point where you froze it, not just statements you happened to log.
With logs, the way you debug is you log some state, reset the program with more logs and iterate until you find an issue. With a debugger you freeze the program examine all the state .... advance the program however far you want.... then the issue is found (unless you advanced the state too far ... but with logging the state ALWAYS advances too far until the end of execution, so with logging you always need to reset).
Logically, logging is just debugging with less features so people who prefer logging just in general don't want to use the extra features. Additionally logging has the added downside of constantly polluting your pristine code with your log annotations which you have to remove later (can introduce more bugs). While debugging with console PDB has the same effect, a GUI largely alleviates this problem.
The only argument for logging/printing is that you can use logging to debug an application in production.