On 9/7/2017 12:50 PM, Barry Warsaw wrote:
On Sep 6, 2017, at 23:10, Terry Reedy <tjre...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
