Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to Python Debugging

martinheinz.dev

Post reply on HN
Print view View original

141–149 of 149 posts

Re: Guide to Python Debugging

#141

Post by markus_zhang »

dijit wrote: post #43
markus_zhang wrote: post #15

Earlier quoted context omitted.

Agreed to every point. Pycharm really shocked me by correctly suggesting most of library related stuffs as ling as I type hint them. I really enjoyed pycharm and datagrip and wondering how does clion compare with vs.

I've been using CLion with the 'rust' plugin, which is quite nice. But it's not pycharm; the debugger is very much lacking, often failing to resolve or step through. But this is likely because Rust is not a primary target for the IDE.. I haven't tried any complex C++ in it yet.

Thanks. Maybe I'll try it out. The only downside of Jetbrain tools is that they consume a lot of memory, but should be fine on my side.

Re: Guide to Python Debugging

#144

Post by BerislavLopac »

0x008 wrote: post #35
_coveredInBees wrote: post #3

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 tried pycharm once and every time i started it up it had to index files for hours. Anybody got around that problem? I really like IntelliJ so I would love to give pycharm a try.

Everything you can do with PyCharm you can do with IntelliJ with the Python plugin; in fact, the plugin and PyCharm share the underlying code base.

Re: Guide to Python Debugging

#145

Post by koyote »

crimsonalucard1 wrote: post #119
david_draco wrote: post #96

Earlier quoted context omitted.

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…

I completely agree and was just about to make a post comparing logger/debugger to bike/car. I guess we think alike!

There are also quite a few bugs where you need some kind of debugger in order to track down the bug. I am thinking crash dumps (using WinDbg for example) as well as memory corruption in C/C++. Being able to set a breakpoint when a certain address in memory changes has basically reduced most memory corruption bugs from a week-long nightmare to more of an inconvenience for me (mind you, it's still my least favourite type of bug to investigate).

Re: Guide to Python Debugging

#146

Post by pjmlp »

kingosticks wrote: post #121
pjmlp wrote: post #115

Earlier quoted context omitted.

My "first class" remark is because it comes from Microsoft itself and isn't a third party plugin.

Would "first-party" be more accurate? First-class implies it's the best. Which it is not.

I guess so, not native speaker, thanks.

Re: Guide to Python Debugging

#148

Post by crimsonalucard1 »

snazz wrote: post #123
crimsonalucard1 wrote: post #119

Earlier quoted context omitted.

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…

I find that print debugging forces me to think through the execution and understand what my program is doing in my head. By having the restriction of not being able to change my print statements without restarting the program, I'm forced to understand the program better. Some restrictions foster creativity. I will add that I usually add various levels of debug log annotations even before I run into a bug so that I kn…

Yeah logging is like a bike. Generally worse than the car but good for you in terms of exercising your brain.

Re: Guide to Python Debugging

#149

Post by mgalgs »

kikoreis wrote: post #100

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!

Or if you have ipython installed:

    import ipdb; ipdb.set_trace()
which gets you a slightly fancier pdb.
Post reply on HN