Forum Archive

@omz, the debugging window you bring up is sort of ok. However there are a quite a few issues , I have refrained from commenting about it because of being in beta. The stack view often points to lines a few after where the actual error really is in the code. It still affects me a little, but not so much as I learn more about Python . I can spot the problem mostly. But it was in the beginning when I was learning, I would have been so lost. Especially for new Python people, it needs to be 100%.

The other thing is in the 'variable' list you have local and global. Global is always a huge list.
On this method, I get an error, expected number.

w, h = ui.measure_string(self.text,
                max_width=self.max_width,
                font=(self.font_name, font_size),
                alignment=self.alignment,
                line_break_mode=self.line_break_mode)

But the pop up trace is not much help to find the problem. I am sure it's there, but not easy to find amongst the globals.

I get this -

But would be great if you could have something like a global context list. Meaning a list of globals actually referenced inside the method/func.

I have no idea about the complexity of this, but earlier versions of py2 beta seemed to help you a lot more, at least for me it did

All of the things you pass as arguments to measure_string are instance variables, so they are accessed via the method parameter self and not via globals. A feature to show only globals that are actually used in the function would be nice, if that can be implemented easily.

@Phuket2 Have you looked at online python tutor(visualizing debugging) tool?
http://www.pythontutor.com/
It could show nice visualization of stack variables, global variables etc. I use it sometimes to debug my non-ui python programs. May be omz can take some ideas from there.

I will say the three main things the debugger needs are:
1)some sort of scrolling /wrapping for long exceptions. or pop up with the full text, etc. I find that often I cannot tell what the exception is, because it is too long for the tiny box.
2) an interactive console. this is tricky, and is sort of where my previous attempt at a debugger got stalled. maybe the ability to launch a pdb session from the current frame.
3) ability to live edit variables and attributes. though this would not be needed with an interactive console.

Also, it would be awesome if history was stored during pdb sessions. Or have the option of history being stored for all console input (raw_input's) not just in the main interpreter.