Sublime Forum

Need recommendation on debugger, variable and stack views

#1

Love using ST3 for editing, visualization of code, but need a debugger with variable value views, stack, step-by-step execution. Recommendations? Part of ST3 that I just don’t see? Seems kinda silly to have a great editor without a complete solution for development… What am I missing? Can do I use ST3 as part of an overall integrated development environment? Thanks!

0 Likes
#2

You’re not missing anything, there is no built in debugger.

Sublime is intended for (and bills itself as) a text editor, not an IDE. There is a pretty rich plugin ecosystem but the API that sublime provides doesn’t include anything that would allow the plugin to add anything to the GUI, which limits the sort of interactions you could have with it.

0 Likes
#3

Thanks! OK, so I’m getting ST3… Now for the real question. What do real developers use for an IDE (for Python, in my case). Gotta have a debugger… Any recommendations? Right now, I’m adding way too much VERBOSE=True/False If VERBOSE: Print(“X is {} and y is P{} and this is loop {}”.format(yadayadayada) which works but is not a real solution for complex programs…

0 Likes
#4

That’s the way I’ve always done it. I find debuggers too slow and finicky. If you find that doesn’t work for a “complex program” then the bug is the complexity.

0 Likes
#5

The first IDE for python that comes to mind is PyCharm, followed by Wing. I’m sure there are probably others as well.

I haven’t used an IDE for anything (outside of Java) in a long while though, so I don’t know how they might stack up against each other.

0 Likes
#6

Thanks nutjob2. So when you write in the debugging code, do you create an on/off switch that can be different for different functions? Just one VERBOSE? Something really creative like VERBOSE = “101011” where you can turn on/off different parts or the program? If you have lots of functions, how do you deal with this?

0 Likes
#7

You didn’t ask me, but personally I put debugging prints like that in only when I’m trying to track something that is not working. Once everything is working properly, I remove them or comment them out.

I tend to write everything in smaller self contained chunks that have their own internal error checking. I also go out of my way to make sure that I’m testing everything as I go along so that if I encounter a problem I can be fairly sure that the issue is with what I just did.

As @nutjob2 said, if that sort of approach doesn’t work, your code may be too complex; hard to debug is also hard to maintain.

2 Likes
#8

Basically what OdatNurd said, I usually put a debug flag in each function that I want to debug, that is local to that function, and turn them off and on as needed. Usually there’s only a handful of functions at most that need to be logged. It’s not elaborate because I usually don’t have to revisit stuff once it works.

ST does help with logging, since I output mine with a filename and a line number so that I can double click on the output and see the context quickly (I run the program with the build system).

To expand on what I said earlier, if your program is hard to debug, it’s probably becuase you don’t really understand what it’s doing anymore, and you’re better off stepping back and restructuring the code so that it makes more sense, or writing the code so that it hides detail and lets you think about the problem in a way that is closer to how you’re thinking about it in your head.

I think “real developers” tend to use structure and abstraction rather than debuggers and other such tools becuase it’s quicker and easier in the long run, even if it hurts to throw away code you’ve slaved over trying to make work for hours or days. Eventually you learn to throw stuff away sooner.

1 Like
#9

I use PyCharm Professional. It has everything you want for a Python IDE.
Perhaps that is more than most people want, but I like it.

0 Likes
#10

For me @OdatNurd’s solution is the best one. If you leave your if VERBOSE statement everywhere, your code become quickly disgusting (at least what I picture).

Without trying, here’s what I think you could try: instead of writting debugger (or whatever you have to write to pause your program), write exit(). Then, run your program like this

python -i my_python_script.py

You’ll be able to type python code after this, with all the vars that existed when you that are available at this stage. There is two problem though:

You get an exception, which is not really nice. You can do this to prevent it though:

def stop():
try:
    exit()
except:
    pass

foo = 'bar'
bar = 'foo'
stop()
hello = 'world'
world = 'hello'

Here, you’d be able to access foo and bar.

You can do this only once

You can’t pause your program more than once.

0 Likes