This is all great feedback! My bugs.python.org userid is: IrvKalb
As I am new to the world of IDLE development, do changes you are making (or considering), also make it into a release for Python 2.7.x? My schools still install 2.7 for use in all of our classes. Irv On Nov 1, 2016, at 8:56 PM, Terry Reedy <tjre...@udel.edu> wrote: > On 11/1/2016 3:17 PM, Irv Kalb wrote: >> 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 > > This is helpful information. I snipped some of your text in responding below. > >> seamlessly. No breakpoint(s), no debugger. If this is implemented, >> then there should also be some quick way to remove all breakpoints. > > Good idea. Should be easy to do. > >> Another approach would be as you suggested, a “Run with Debugger” > > I think of this as an alternative to run debugger if there are no breakpoints. > >> 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. > > The debugger currently selects or otherwise tags the next line, though this > has been a problem on windows. > >> 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. > > What I specifically think a bug is stepping into idlelib code that would not > be involved if not running in idle. The print function is especially notable > in this respect. Stdlib and 3rd party library module are a difference > subject. > >> 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. > > I think this would be the proper default for most users. > >> 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. > > Yeah, me possible wanting to the debugger to step into idlelib code is > extremely specialized. I could stand to set an option in the preferences > dialog. > >> 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.) > > (I think that the best way to explain it as 'cross-namespace assignment', > with the caveat that the interpreter will gather 'extra' args into a tuple or > dict if the function signature requests. The important point is that *for > Python* a parameter binding acts the same as a binding back in the calling > namespace. In particular, and importantly, > > a = [1] > b = a > b.append(2) > print(a) > # [1, 2] > > has the same result as > > a = [1] > def f(b): > b.append(2) > f(a) > print(a) > # [1, 2]) > >> 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 > > I never thought of it as a 'hack', but do consider it an unnecessary nuisance > (extra step). This is one my possible changes list. I also have thought of > underlining the file-line part to make it be a link. The plus would be the > visual clue to 'click here' to make the jump. The minus would be having to > click the link and not just anywhere. > >> 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 thought about moving that to the top of the menu. But click would be > even easier. > >> (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.) > > Again, precedent is helpful. > >> 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. > > Send me your bugs.python.org userid if and when you have one. > > 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
