Im not sure if this is by design or a bug.
If you have no breakpoints in your program and you click Debug, Mu runs the program to completion, from a users perspective it is the same as clicking Run.
The debugger only stops execution of the code and allows it to be debugged if you have placed a break point in your program.
This creates a little friction for the new user, as they have to know how to create a break point before they can debug their code.
As an alternative - when the debugger starts, could it break point on the first line allowing the user to run to the next breakpoint, step through, etc.
Hi @martinohanlon,
This is by design. We assume the user knows what line they want to break on. Furthermore, there's no guarantee that the first line (or any subsequent lines) are lines that Python will break on (for example, the first line may be -- and probably is -- a comment). In which case, we'd have to try to write something complicated to analyse the code and work out where the first break must be. Of course, there's still no guarantee that it's the right place... hence the conservative approach of trusting the user.
This is all explained in the debugger tutorial and howtos on the new website (which will also be available via the Mu help button). Incidentally, Mu attempts to heuristically detect if you're trying to drop a breakpoint on a non-breakable line, although this is more a "best effort" 80/20 type solution. A more robust solution would be to use, say, the built-in AST module to analyse the user's code (assuming it's correct) to work out the various attributes of the code... although this is likely to be a big block of work and something to do for Mu2.0 (based on evidence from users' and teachers' experiences with the debugger).
I hope this makes sense.
This was bothering me... I think I've found a way built into Python's bdb class that'll help me solve this. I'll re-open and hopefully re-close later this afternoon once I've done some further investigation.
Hah... I've fixed it with a conditional statement and the built-in set_trace method which I didn't realise worked in the way it did (exactly the way we needed it to) if we don't supply any args. ;-)
OK... it works! :-) Hurrah for Python having unknown but exactly-what-I-needed features. ;-)
Excellent, great result.
Most helpful comment
OK... it works! :-) Hurrah for Python having unknown but exactly-what-I-needed features. ;-)