[Idle-dev] Enhancements to IDLE debugger

[Irv Kalb]

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 <tjreedy at 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 at python.org
> https://mail.python.org/mailman/listinfo/idle-dev