Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15335
___
___
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15335
___
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: -serhiy.storchaka
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15335
___
Roger Serwy roger.se...@gmail.com added the comment:
I suggest to add a decorator @Debugger.internal for all methods that the
debugger should not step into. It should set a function attribute that the
debugger then checks for.
The decorator idea may work. I'll need to see how to make it
New submission from Roger Serwy roger.se...@gmail.com:
The IDLE debugger steps through the internals of _RPCFile.
To reproduce this bug, create a new .py file with a few print statements,
enable the debugger, and then run the file. Stepping through the print
statement enters into _RPCFile.
Roger Serwy roger.se...@gmail.com added the comment:
Debugger.py has a method in_rpc_code which ultimately prevents stepping
though code from rpc.py. (Presently an external file named rpc.py can not be
debugged using IDLE.)
Adding run.py to the check would prevent run.py from being stepped,
Martin v. Löwis mar...@v.loewis.de added the comment:
I suggest to add a decorator @Debugger.internal for all methods that the
debugger should not step into. It should set a function attribute that the
debugger then checks for.
OTOH, I fail to see the problem. Stepping through the standard
