From Irv at furrypants.com Tue Nov 1 15:17:53 2016 From: Irv at furrypants.com (Irv Kalb) Date: Tue, 1 Nov 2016 12:17:53 -0700 Subject: [Idle-dev] Enhancements to IDLE debugger In-Reply-To: References: <1E062C25-7517-4ECA-B57C-A6D4F9324CF3@furrypants.com> Message-ID: <784AF636-CAB5-4621-8C4C-2AE15ACED9D3@furrypants.com> 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 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 at python.org > https://mail.python.org/mailman/listinfo/idle-dev From tjreedy at udel.edu Tue Nov 1 23:56:41 2016 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 1 Nov 2016 23:56:41 -0400 Subject: [Idle-dev] Enhancements to IDLE debugger In-Reply-To: <784AF636-CAB5-4621-8C4C-2AE15ACED9D3@furrypants.com> References: <1E062C25-7517-4ECA-B57C-A6D4F9324CF3@furrypants.com> <784AF636-CAB5-4621-8C4C-2AE15ACED9D3@furrypants.com> Message-ID: 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 From Irv at furrypants.com Sat Nov 5 19:19:11 2016 From: Irv at furrypants.com (Irv Kalb) Date: Sat, 5 Nov 2016 16:19:11 -0700 Subject: [Idle-dev] Enhancements to IDLE debugger In-Reply-To: References: <1E062C25-7517-4ECA-B57C-A6D4F9324CF3@furrypants.com> <784AF636-CAB5-4621-8C4C-2AE15ACED9D3@furrypants.com> Message-ID: <54E71202-B5F1-49D8-8484-518E14B83E57@furrypants.com> 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 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 at python.org > https://mail.python.org/mailman/listinfo/idle-dev From tjreedy at udel.edu Sat Nov 5 22:34:46 2016 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 5 Nov 2016 22:34:46 -0400 Subject: [Idle-dev] Enhancements to IDLE debugger In-Reply-To: <54E71202-B5F1-49D8-8484-518E14B83E57@furrypants.com> References: <1E062C25-7517-4ECA-B57C-A6D4F9324CF3@furrypants.com> <784AF636-CAB5-4621-8C4C-2AE15ACED9D3@furrypants.com> <54E71202-B5F1-49D8-8484-518E14B83E57@furrypants.com> Message-ID: On 11/5/2016 7:19 PM, Irv Kalb wrote: > 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? While there is greater latitude for backporting IDLE changes than for the rest of the stdlib, I have pretty much stopped patching 2.7. I posted why last January (but have made a few changes since). 1. 2.7 is used by people who want stability, not change. 2. It is too hard to adequately test. A year ago I introduced bug into 2.7 as a result. A new third reason is that with 3.6, I can and have started using the ttk widgets introduced a decade ago. When I redo the debugger window, I will switch it to ttk, as I already have done, am doing, or will do with everything else. > My schools still install 2.7 for use in all of our classes. Then they must want stability over enhancement ;-). -- Terry Jan Reedy From Irv at furrypants.com Sun Nov 6 15:39:41 2016 From: Irv at furrypants.com (Irv Kalb) Date: Sun, 6 Nov 2016 12:39:41 -0800 Subject: [Idle-dev] Enhancements to IDLE debugger In-Reply-To: References: <1E062C25-7517-4ECA-B57C-A6D4F9324CF3@furrypants.com> Message-ID: I finally got a chance to look through the IDLE debugger issues. The big one for me, is the first one, 17942. I agree with your comment that ?IDLE should execute and debug user code as transparently as possible?. On Oct 31, 2016, at 6:47 AM, Terry Reedy wrote: > 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? Yes, this would be very helpful. Another choice for a user interface would be a disclosure triangle. Click on the triangle, and it opens to show the values of the attributes, click it again, and it closes up. (I have seen it done this way in other debuggers.) > zzzzz At each step, color changed values. This would be extremely helpful to students. > nnnnn Suppress dunder names in globals list, so starts empty. Agreed. Students don?t really understand the dunder names. > ppppp locals/globals min space for vars and space between longest and value Not really sure what this means? > ddddd break on data change since monitor anyway? Data change breakpoints would be extremely helpful > mmmmm No Breakpoint setting on context menu? If this means that the user sets breakpoints by clicking to the left of the source line (on a line number if it is there, or in a dedicated column to the left of the line), then, in my opinion, this is the single most important thing. Thanks, Irv -------------- next part -------------- An HTML attachment was scrubbed... URL: From Irv at furrypants.com Sun Nov 6 15:41:59 2016 From: Irv at furrypants.com (Irv Kalb) Date: Sun, 6 Nov 2016 12:41:59 -0800 Subject: [Idle-dev] Enhancements to IDLE debugger In-Reply-To: References: <1E062C25-7517-4ECA-B57C-A6D4F9324CF3@furrypants.com> <784AF636-CAB5-4621-8C4C-2AE15ACED9D3@furrypants.com> <54E71202-B5F1-49D8-8484-518E14B83E57@furrypants.com> Message-ID: Yes, my schools definitely value stability. In fact, I tell the students that if they encounter a bug when running a program, they can be assured that the bug is in their code and not in Python or IDLE (version 2.7). Irv On Nov 5, 2016, at 7:34 PM, Terry Reedy wrote: > On 11/5/2016 7:19 PM, Irv Kalb wrote: >> 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? > > While there is greater latitude for backporting IDLE changes than for the rest of the stdlib, I have pretty much stopped patching 2.7. I posted why last January (but have made a few changes since). 1. 2.7 is used by people who want stability, not change. 2. It is too hard to adequately test. A year ago I introduced bug into 2.7 as a result. A new third reason is that with 3.6, I can and have started using the ttk widgets introduced a decade ago. When I redo the debugger window, I will switch it to ttk, as I already have done, am doing, or will do with everything else. > > > My schools still install 2.7 for use in all of our classes. > > Then they must want stability over enhancement ;-). > > -- > Terry Jan Reedy > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > https://mail.python.org/mailman/listinfo/idle-dev > From alan.gauld at yahoo.co.uk Wed Nov 9 05:31:03 2016 From: alan.gauld at yahoo.co.uk (Alan Gauld) Date: Wed, 9 Nov 2016 10:31:03 +0000 Subject: [Idle-dev] Enhancements to IDLE debugger In-Reply-To: References: <1E062C25-7517-4ECA-B57C-A6D4F9324CF3@furrypants.com> <784AF636-CAB5-4621-8C4C-2AE15ACED9D3@furrypants.com> Message-ID: On 02/11/16 03:56, Terry Reedy wrote: > 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. I'd vote for that, I can think of several reasons why a single click anywhere on the error message causing a jump would be "a bad thing" - not least trying to cut 'n paste it into a mail. But clicking on a link causing a jump is expected behaviour nowadays. And definitely better than the current right-click/menu solution. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos