Hi, 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 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 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.) 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. 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. 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 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.) 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. 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. 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 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 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. Having a combination of line numbers AND a simpler debugger interface would be ideal! Thank you very much for your consideration, Irv _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
