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

Terry Reedy tjreedy at udel.edu
Thu Sep 7 16:52:10 EDT 2017

On 9/7/2017 12:50 PM, Barry Warsaw wrote:
> On Sep 6, 2017, at 23:10, Terry Reedy <tjreedy at udel.edu> wrote:
>> Environmental variables are set to strings, not objects.  It is not clear how you intend to handle the conversion.
> The environment variable names a module import path.  Without quibbling about the details of the syntax (because honestly, I’m not convinced it’s a useful feature), it would work roughly like:
> * The default value is equivalent to PYTHONBREAKPOINTHOOK=pdb.set_trace
> * breakpoint() splits the value on the rightmost dot
> * modules on the LHS are imported, then the RHS is getattr’d out of that
> * That’s the callable breakpoint() calls

Environmental variables tend to be a pain on Windows and nigh unusable 
by beginners.  Leaving that aside, I see these problems with trying to 
use one for IDLE's *current* debugger.

pdb is universal, in the sense of working with any python run with 
actual or simulated stdin and stdout.  IDLE's idb is specific to working 
with IDLE. So one could not set an EV to 'idlelib.idb.start' and leave 
it while switching between IDLE and console.

pdb runs in one process, with communication between debugger and text ui 
handled by call and return.  It can be started on the fly.  IDLE runs 
code in a separate process.  The debugger has to run in the user 
process.  IDLE currently runs the GUI in the IDLE process.  So a 
complicated communication process has to be set up with rpc proxies and 
adaptors, and this is best done *before* code runs.  The on-the-fly 
function should not need an import and it might be better to not have one.

pdb.set_trace is a public and stable interface.  IDLE's is private and 
likely to be initially unstable.  I can imagine that the function that I 
would want to bind to sys.__breakpoint__ would be a bound method

Thinking about the above prompted me to rethink IDLE's debugger and 
consider rewriting it as an IDLE-independent gui debugger.  I'll will 
say more in response to Guido and you.

Terry Jan Reedy

More information about the Python-Dev mailing list