[Python-Dev] PEP 553: Built-in debug()

[Guido van Rossum]

On Wed, Sep 6, 2017 at 11:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 9/6/2017 6:45 PM, Barry Warsaw wrote:
>
>> On Sep 6, 2017, at 14:59, Terry Reedy <tjreedy at udel.edu> wrote:
>>
>>>
>>> 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.
>>>
>>
>> Would the environment variable idea in the latest version of the PEP help
>> you here?
>>
>
> That seems to be a mechanism for users to convey which function to call.
> It does not simplify the function call chosen.
>
> 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.
>
> 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.
>

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.


> 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.
>

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.

(Plus there's something about old dogs and new tricks, but I've forgotten
exactly how that one goes. :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170907/db2d58e0/attachment.html>