Reputation: 3040
My current makeshift approach is logging to a textfile, but that isn't very interactive. I've tried using pdb, but that doesn't seem to get along with urwid, pdb
doesn't take any input once it hits a breakpoint.
Upvotes: 7
Views: 794
Reputation: 81
just in case anyone's searching for a better answer, I can report that VSCode's Python debugger debugpy is excellent for debugging urwid applications (and for debugging Python generally.) Your debugger is entirely separate from the console and doesn't interfere with drawing.
Upvotes: 0
Reputation: 23806
One thing I've found myself doing is to add a text widget just to display debugging messages.
I haven't built many complicated apps (a solitaire game was the biggest app i wrote with it), so this approach was good enough.
In some specific cases, you might still be able to get away using PUDB -- but since it's also using Urwid, it will steal the output from the app. In practice, after you go from your app to pudb (maybe from a pudb.set_trace()
breakpoint added to your code), then you won't be able to get back to your app.
For more complex applications it might be interesting to build a "debug mode", or maybe you could try using remote pudb? Haven't tried that yet, but it looks useful. =)
Upvotes: 2
Reputation: 113
A couple of practices down the line... Debugging urwid is strange and not really well possible in the classical sense, most of the time after rendering the canvas you can't really check things anymore.
What helped me:
n+1
-time is a good idea.I know that doesn't really count as debugging, but it helped me a lot in finding errors or strange behavior.
Upvotes: 5