Terry, What a pleasure to meet you. Thanks for all your comments. I’m happy to give you my opinions on the items you raised.
1) If it is possible to start the debugger automatically whenever there is a breakpoint in the code, I think that would be ideal. I have used systems that work this way, and that approach works seamlessly. No breakpoint(s), no debugger. If this is implemented, then there should also be some quick way to remove all breakpoints. Another approach would be as you suggested, a “Run with Debugger” menu option (with some appropriate shortcut key, maybe Command/Control F5). Anything that allows the user to start the debugger from the editor window, rather than having to select it from the Shell window would be a great improvement. Thanks for the historical explanation for why it might have been done this way. However, from the simple user’s perspective, it’s not very intuitive. 2) Clicking on the line number to set a breakpoint would be great. I didn’t suggest that because there currently are no line numbers. Changing the background color of the line number would be fine (red to indicate a breakpoint?). As you probably know, debuggers typically also have an arrow of some type to indicate the next line of code that is about to execute. This arrow is typically drawn over the breakpoint indicator when you reach a breakpoint, and moves as you step through or over code. 3) In my reference to PythonTutor, I was not suggesting a specific change. I was saying that I want to demonstrate the flow of control in programs in class, and I currently resort to doing it by using PythonTutor for this purpose. If the enhancements being discussed here were all implemented, I would certainly be able to do this demonstration using the IDLE debugger instead. 4) Sorry I wasn’t clear about “other people’s code” - I was not talking about Python library code. What I meant was that if someone sends me some of their code, or I try to run some code that I might find on the internet, of course, the first thing I do is to read through the code. However, if there are parts that I am unsure of, I tend to use a debugger to step through the code to understand the typical flow of execution, and look at variables to see what is going on. 5) I can certainly understand that stepping or not stepping into Python library code could be a contentious issue, and I’m glad to hear that you regard it as a bug. With respect to how this could be handled, my view would be that an overwhelming percentage of people who use IDLE for development are students. And as such, that percentage would not want to step into library code. Therefore, I would propose that “Run with Debugger” should not pop up a box every time it is selected. Instead, I would much prefer this to be a preference. And if so, probably the best choice for a default would be Directory of current file. This would allow users who are sophisticated enough to understand that they might want to step into library code the ability to do so, but would work in an expected way for novices, all without having to deal with a dialog box on every run with the debugger. 6) Yes, it is very interesting to work with students who are completely new to programming. (As an aside, the single thing that is most difficult for students to grasp is the way that arguments are passed to function and how they are assigned to parameter variables in the called function.) 7) I wil look through the list of bugs and see if I have anything to add. I will also write up some comments on your “other possible changes”. 8) Yes, I am aware of the right click on the traceback line to jump to the file and line indicated. And I do teach that to students that are a little more advanced. But to me this seems like a little bit of a hack. Is there any reason it can’t be just a click on the error message line to do the same thing? Every time I’ve use it, I see a pop-up menu that starts with Cut, Copy, Paste - but these options are always grayed out. The only available option is "Go to file/line”. (I have used other systems where clicking on a similar error message goes to the appropriate line, and this seems like a simple/reasonable approach which works well.) I thank you very much for your feedback, and I look forward to being in touch. Please let me know if there is any more information I can provide. I would also be happy to be a beta tester of any changes to the Debugger. Irv On Oct 31, 2016, at 6:47 AM, Terry Reedy <tjre...@udel.edu> wrote: > On 10/30/2016 6:00 PM, Irv Kalb wrote: > >> I am new to this list, so here’s a quick introduction. I have been a >> software developer for over 30 years. I’ve worked for a number of >> different companies and then worked for many years as a consultant. >> Over the course of my career, I’ve used many different languages, >> many operating systems, and many different development environments. >> I’ve worked on the development of operating systems, compilers, user >> interface work, kids edutainment software, eLearning systems and >> more. >> >> For the past six years, I’ve been teaching software development at >> three different colleges in Silicon Valley, California. I mostly >> teach intro to programming, using Python. Most of my students are >> not Computer Science majors, in fact, most are art students, and most >> have never done any programming before. In my classes, I teach my >> students to use IDLE because it is installed as part of the standard >> installation on all of the school’s computers. For these students it >> works perfectly. It is simple for them to understand, and there is >> no need to access the command line. > > I am the current IDLE maintainer, still learning some of the darker corners > of idlelib. The debugger is one of them. One of the things I need is more > feedback from users and especially active instructors. Thank you for writing. > >> I am writing to suggest an improvement to the IDLE environment that >> would be of great benefit to students (and to teachers, correcting >> student’s assignments). >> >> In my work as a developer, I got used to working with good debuggers. >> I use a debugger as an invaluable tool to track down bugs in my code, >> and especially in understanding and finding bugs in other people’s > > I mostly use prints and visual tracing, but I would probably be better off > myself if IDLE's debugger were improved and I used it. The IDLE doc still > labels Debugger as "still incomplete and somewhat experimental". I would like > to be able to delete that. > >> code. When I started using Python with IDLE, I was excited when I >> found that it had a debugger. While the debugger has all the basic >> operations, I believe that the way you start the debugger and the way >> that you set breakpoints in IDLE are highly unintuitive. (In most >> other systems, breakpoints are set and cleared by clicking in a >> dedicated column next to the lines numbers, which turns on/off a >> simple dot or stop sign.) > > Starting: I have thought that there should be Debug or Run with Debugger on > the Run menu. If a breakpoint is set, maybe make this automatic. > > The rationale for only starting from the Shell might have been: "Starting > debugger requires connection to a remote user process, which only exists if > Shell is running." Or maybe the current scheme is just a quick hack. In > either case, Run => Run Module starts Shell if it is not running and a run > option could also start the debugger after starting the shell. > > Breakpoints: How about clicking on the line number itself, once they are > available? I have though about changing the line number background to > indicate breakpoint lines. > >> I would really like to use the debugger in a class setting to >> demonstrate stepping through code. For example, I’d like to >> demonstrate how argument values are passed and assigned to >> parameters, and also to demonstrate how control flows through a while >> loop with break and continue statements, etc. I sometimes do this >> in class by copying a small program, and pasting it into >> PythonTutor.org, and run the code that way. But it’s unfortunate >> that I cannot do this easily directly in IDLE. > > I do not understand from the above what change you would like. > >> The current debugger also has a flaw that makes it unworkable in a >> teaching environment. Maybe I’m missing something, but the debugger >> seemingly cannot distinguish between user-written code and library >> code. > > The crucial distinction is between 'code I want to trace' and 'other code'. > User have to indicate that somehow. The current APi is [step] versus [go], > [over], and [out] to skip. Library code is someone's 'user-written code'. > And as you say above, debuggers are especially useful for examining *other* > people's code. That said, Debugger *could* also pay attention to file paths. > > > As an example, if my code is at a breakpoint and is about to >> execute a print statement, and I click on “Step" to step through it, >> the debugger steps into the library code of the print statement > > I now regard this as a bug. See https://bugs.python.org/issue15335. But note > that autoskipping Python code is a contentious idea. A previous maintainer > wrote "I fail to see the problem. Stepping through the standard library may > be useful, and if you don't want to do that, you can choose to step over > still." > >> itself. While I understand what is going on here, it would be >> impossible to explain this behavior to students who not only are new >> to debuggers, but new to programming. Ideally, the Step button >> should only step a single line of the user’s code. (PyCharm has this >> feature built into its debugger.) > > Leaving PyCharm aside, what API might you like to see? 'Run with Debugger > could pop up a box with > > Restrict stepping to > [ ] Current file > [ ] Directory of current file > [ ] Directory ______________________ > [x] Any Python file > >> Beginning students see the Python runtime as a black box. I do >> explain that the standard way of finding out what is going wrong with >> their programs by adding print statements. However, students find >> that approach to be time consuming, and the output can be confusing >> as it may not be clear how the code got to certain print statements. > > Interesting observation. I have long forgotten whatever learning curve I > went through to become expert at this. > >> Instead, students typically wind up just making small changes to >> their code or adding new code, and look at how the results change. I >> would love to explain how to my students how to use a debugger to >> step through code and watch the values of their variables change. >> But in its current form don’t even try to use the IDLE debugger in >> class. >> >> I have read through the documentation of recent open issues, but I >> haven’t seen anyone making any comments about the debugger. > > Here is my list of open bugs.python.org IDLE debugger issues. > -Debugger > 17942 Improve gui > 15335 Steps over Idle rpc code, but into Idle print code > 22083 Refactor breakpoint methods > 14111 Handle interrupts > 15347 Debugger activation disrupts closing even after debugger closed (Close) > 15348*Closing [x] while active freezes shell (Serwy x 2) > 24455 Closing twice while running caused crash. > 24090 Send name value, possible truncated, to clipboard > 24818 Isolate Shell connection so can run file without shell already open > 25254 Highlight in source window again not working. > 25146 Program visualization with intelligent auto step. > 26949 raise SystemExit while debug causes extra Restart Shell > > Feel free to post comments on the tracker (or here). > > Here are some personal notes on other possible changes. > > xxxxx Inspect attributes of global/local object, possible rt. click? > zzzzz At each step, color changed values. > nnnnn Suppress dunder names in globals list, so starts empty. > ppppp locals/globals min space for vars and space between longest and value > ddddd break on data change since monitor anyway? > mmmmm No Breakpoint setting on context menu? > https://python4kids.brendanscott.com/2015/09/02/python-for-kids-book-project-6/ > > > As a >> teacher, having an easy-to-use debugger in IDLE would tremendously >> beneficial in student’s ability to understand and debug Python code. >> >> Maybe this should be a separate issue, but it would also be a great >> help if the lines of a program in the IDLE editor had line numbers > > https://bugs.python.org/issue17535 > >> next to them. It would make teaching concepts much easier to say, >> "look at lines 14 and 15 of your program", rather than pointing at >> them with my fat fingers to draw attention to where a student made a > > This is pretty convincing. I need to review the current patch and perhaps > accept something less than 'perfect'. > >> mistake. It would also be much easier for students to identify the >> line numbers that appear in Python error messages, rather than having >> to click around in their source code and watch the line number change >> in the bottom right hand corner. > > Are you aware, and do you teach students, that one can right click on a > traceback line and jump to the file and line indicated? Ditto for grep (Find > in Files) output. This is why I have not so strongly felt the need for line > numbers myself. > > > Having a combination of line >> numbers AND a simpler debugger interface would be ideal! > > Again, thanks for the feedback. I agree and hope to implement both. > > -- > Terry Jan Reedy > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > https://mail.python.org/mailman/listinfo/idle-dev _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
