Live data from Hacker News

Guide to Python Debugging

martinheinz.dev

51–60 of 149 posts

Re: Guide to Python Debugging

#51
I’ve always admired pdb.set_trace() as a way of inserting a debugger breakpoint. I’m surprised it isn’t mentioned in the article.

You don’t need a different UI for debugging — you can just write the breakpoint into the code. Conditional breakpoints can be done with Python logic!

Marvelous!

Re: Guide to Python Debugging

#52
The article has a couple of problems in my eyes:

- "you might want to just copy-paste it and use it" ... that's maybe what people end up doing, but it's a terrible idea.

- The following `__repr__` is out of alignment with the output printed below it:

    class Circle:
        def __init__(self, x, y, radius):
            self.x = x
            self.y = y
            self.radius = radius

        def __repr__(self):
            return f"Rectangle({self.x}, {self.y}, {self.radius})"
The class name is hardcoded; maybe use:

    def __repr__(self):
        name = self.__class__.__name__
        return f"{name}({self.x}, {self.y}, {self.radius})"
- There's a bare `except` in the `traceback` demo. It is not a problem in this toy example and works, but bare `except` statements have no place in educational code. Some poor soul will copy-paste it and run into awful errors down the line (https://realpython.com/the-most-diabolical-python-antipatter...)

Re: Guide to Python Debugging

#53

I've been a Python developer for more than ten years. Approximately 98% of the time I need to debug something I use print() statements and this: import IPython; IPython.embed()

I've been a Python developer for less than 10 hours. Approximately 98% of the time debugged something was in Visual Studio. Quite a nice experience. I was lucky to have the project already set up for me.

Re: Guide to Python Debugging

#56

Don't forget breakpoints! Learn how to move around in the debugger, it will be a LIFESAVER. Above a troublesome line of code, drop this line: import pdb; pdb.set_trace() And run it as normally. Now you can explore. Drop into the function, step forward, go up. You just need to learn to move around. With pdb you can really explore what's going on.

Or even just breakpoint() built-in in python 3.7+ In addition you can set PYTHONBREAKPOINT=ipdb.set_trace (or whatever you prefer) in your shell rc file

It has really bothered me that `breakpoint()` didn't start ipdb when running a script using ipython.

I guess this is a good workaround!

Re: Guide to Python Debugging

#57

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 agree. After criticizing print statements, more than half of the article discusses logging, which is a little more organized print. And I'm not disagreeing - it's invaluable in production systems.

I wish there was more to how to actually debug in Jupyter or Spyder, and I'm relatively new to both, and was hoping for some tips on that.

Re: Guide to Python Debugging

#58

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).

My main reason for wishing to be able to switch to Vscode instead of Pycharm is because vscode's remote development UX is really really nice and works a lot better for me compared to the Pycharm way of SFTP-ing files between your local and the remote. My use-case where Pycharm feels a bit deficient is that I have an Ubuntu deeplearning box at work that I can VNC into and develop on whenever needed. I have all my repo…

You could just use sshfs.

Re: Guide to Python Debugging

#59

Earlier quoted context omitted.

Not the person you replied to, but I love vscode from when I did a bunch of React + JS stuff a few years back. I also do a ton of software development and machine learning work in Python now and have never managed to move away from Pycharm even though I'd love to be able to have a good enough experience in Vscode so that I could make the switch from Pycharm (the remote development experience in vscode is really neat…

I have used both softwares but stick with VSCode for Python, simply because it is very powerful to have one great editor for all projects, as opposed to one specialized IDE for each. PyCharm is (AFAIK) monolithic in what it brings to the table, whereas VSCode is more modular. As such, some of your points are true, but not an inherit fault of VSCode, but probably of some settings/underlying tools used. Maybe these can…

You are forgetting that PyCharm is actually IDEA, which is an IDE for all languages out there.

Re: Guide to Python Debugging

#60
post #32

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…

Yeah I agree entirely on Pychaem debugger being awesome. But it’s no substitute for logging in production. Somethings just need to be logged, either for proof or those situations where you just can’t reasonably attach a Pycharm debugger.

Production logging with accurate and precise timestamp is an absolute time saver. That means like 1ms timestamp and NNTP synchronized servers.
Post reply on HN