<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 6, 2017 at 11:59 PM, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/6/2017 6:45 PM, Barry Warsaw wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sep 6, 2017, at 14:59, Terry Reedy <<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Currently, the debugger is started in response to a menu seletion in the IDLE process while the python process is idle.  One reason for the 'idle' requirement' is because when code is exec-uting, the loop that reads commands, executes them, and sends responses is blocked on the exec call. The IDLE process sets up its debugger window, its ends of the rpc channels, and commands to python process to set up Idb and the other ends of the channels.  The challenge would be to initiate setup from the server process and deal with the blocked loop.<br>
</blockquote>
<br>
Would the environment variable idea in the latest version of the PEP help you here?<br>
</blockquote>
<br></span>
That seems to be a mechanism for users to convey which function to call.  It does not simplify the function call chosen.<br>
<br>
pdb works because a) it is designed to be imported into and run in a user module and b) it uses the existing stdin and stdout streams to interact with the user.  Idb, on the other hand, is designed to be import in idlelib.run, which is (almost) invisible to user code, and use a special channel to the GUI window.<br>
<br>
Having said that, I see a solution: before running user code, set things up as now, except do not start tracing and do not show the debugger window, but do set a run.idb_ready flag.   Then breakpoint_handler() can check the flag and start tracing either through idb or pdb.<br></blockquote><div><br></div><div>Without following all this (or the PEP, yet) super exactly, does this mean you are satisfied with what the PEP currently proposes or would you like changes? It's a little unclear from what you wrote.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What makes breakpoint() less than super useful in IDLE is that IDLE already allows setting of persistent breakpoints on a line by right-clicking.  Since they are not stored in the file, there is nothing to erase when one runs the code in Python directly.<br></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I think that's true for any IDE that has existing integrated debug capabilities. However for every IDE I would hope that calling breakpoint() will *also* break into the IDE's debugger. My use case is that sometimes I have a need for a *conditional* breakpoint where it's just much simpler to decide whether to break or not in Python code than it would be to use the IDE's conditional breakpoint facilities.</div><div class="gmail_extra"><br></div><div class="gmail_extra">(Plus there's something about old dogs and new tricks, but I've forgotten exactly how that one goes. :-)<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>