Terry J. Reedy added the comment:
In #27615, which I will close as a duplicate of this, Al Sweigart wrote
"Currently if the user "steps into" a print(), input(), sys.stdout.write() or
other stdio-related call with the Source checkbox checked, it brings up
PyShell.py.
This is often confusing for beginner programmers (the target audience of IDLE)
and most often not helpful for experienced developers who are stepping through
their program. Comparing the cost/benefit, I'd be much more helpful for IDLE to
not bring up PyShell.py and instead just treat every "step into" of a
print()/input()/anything-that-goes-to-pyshell as a "step over" instead."
I have changed my opinion from what I wrote a couple of years ago and now
agree. Print and input are different from stdlib functions, such as, "import
asyncio; loop = asyncio.get_event_loop", in that they are used by nearly all
beginners, are not imported, and are normally C-coded builtins that cannot be
stepped into. If one debugs an import- free program, it is startling to be
dropped into foreign code.
IDLE should execute and debug user code as transparently as possible. I now
think that the debugger should not step into any idlelib file unless this is
explicitly requested in a separate check box ('for IDLE maintainers'. I
suspect a blanket no-idlelib or yes-idlelib policy will be faster than the
current code, and would avoid the current bug of not stepping into user code.
I recently moved the Pseudofile definitions from pyshell to run so that run
does not need to import pyshell. I did not consider whether or how this would
affect debugging and should not have to. I plan other refactorings and
movements between files.
Whether to worry about stepping in <frozen importlib._bootstrap> is a different
issue, and one not specific to IDLE.
----------
assignee: -> terry.reedy
nosy: +Al.Sweigart
versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue15335>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
