Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDLE - debugger steps into print and over rpc.py code #59540

Open
serwy mannequin opened this issue Jul 12, 2012 · 8 comments
Open

IDLE - debugger steps into print and over rpc.py code #59540

serwy mannequin opened this issue Jul 12, 2012 · 8 comments
Assignees
Labels
topic-IDLE type-bug An unexpected behavior, bug, or error

Comments

@serwy
Copy link
Mannequin

serwy mannequin commented Jul 12, 2012

BPO 15335
Nosy @loewis, @terryjreedy, @serwy

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/terryjreedy'
closed_at = None
created_at = <Date 2012-07-12.16:42:53.479>
labels = ['expert-IDLE', 'type-bug']
title = 'IDLE - debugger steps into print and over rpc.py code'
updated_at = <Date 2017-10-25.19:28:41.504>
user = 'https://github.com/serwy'

bugs.python.org fields:

activity = <Date 2017-10-25.19:28:41.504>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2012-07-12.16:42:53.479>
creator = 'roger.serwy'
dependencies = []
files = []
hgrepos = []
issue_num = 15335
keywords = []
message_count = 8.0
messages = ['165321', '165324', '165325', '165408', '225248', '225249', '271302', '305007']
nosy_count = 4.0
nosy_names = ['loewis', 'terry.reedy', 'roger.serwy', 'Al.Sweigart']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15335'
versions = ['Python 3.6']

@serwy
Copy link
Mannequin Author

serwy mannequin commented Jul 12, 2012

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.

@serwy serwy mannequin added topic-IDLE type-bug An unexpected behavior, bug, or error labels Jul 12, 2012
@serwy
Copy link
Mannequin Author

serwy mannequin commented Jul 12, 2012

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, but it applies to *any* "run.py" in the filename string:

    elif frame.f_code.co_filename.count('run.py'):
        return True

Or, you could check the name:

    elif frame.f_globals.get('__name__','') == 'idlelib.run':
        return True

Any additional logic for "in_rpc_code" can slow down code performance when debugging.

Another possible approach is to move the _RPCFile into rpc.py add additional methods to RPCHandler, like "get_remote_stdout_proxy".

@loewis
Copy link
Mannequin

loewis mannequin commented Jul 12, 2012

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 library may be useful, and if you don't want to do that, you can choose to step over still.

@serwy
Copy link
Mannequin Author

serwy mannequin commented Jul 13, 2012

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 work with the existing debugging code.

OTOH, I fail to see the problem. Stepping through the standard library may be useful, and if you don't want to do that, you can choose to step over still.

I'm not sure why stepping through an IDE's internals is desirable when debugging one's own program. As it stands, the _RPCFile patch represents an unintended behavior change to the debugger. That needs to be either corrected or documented.

@terryjreedy
Copy link
Member

Since there is currently no '_RPCFile' in idlelib, I presume it was the predecessor of PyShell.PseudoFile. Was it in run.py rather than PyShell.py? Stepping through print (only 1 is needed) steps through the two 'if's and 'return' statements of PyShell.PseudoOutputFile.write.

I agree with Martin that this is not a bug. [step] is supposed to step into python-coded functions and skip over non-python functions and that is what it is doing. Whether *any* stdlib function is coded in python, or something else, or something else and wrapped in python, and therefore whether it will be stepped into or over, is a matter of implementation, version, and local setup. In particular, 'print' was changed from statement keyword to builtin name partly so it could be wrapped or replaced.

However, I agree that stepping through .write is not especially desirable and would not mind if the class were moved from PyShell.py to rpc.py. I think it fits there better anyway.

I wrote a 'rpc.py', not in idlelib, and tried to debug it. Debugger silently ran the whole module and quit, as if I had hit [run] with no breakpoints. This, I think, *is* a bug; in_rpc_code() should only skip over idlelib.rpc code.

@terryjreedy terryjreedy changed the title IDLE - debugger steps through run.py internals IDLE - debugger steps into print and over rpc.py code Aug 13, 2014
@terryjreedy
Copy link
Member

FWIW: stepping into an import statement now steps into <frozen importlib._bootstrap> and for many more statements than the three for print/write. I am already aware that the debugger 'doc' needs to be expanded from
"Debugger (toggle)
This feature is not complete and considered experimental. Run commands in the shell under the debugger "

@terryjreedy
Copy link
Member

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

@terryjreedy terryjreedy self-assigned this Jul 25, 2016
@terryjreedy
Copy link
Member

The debugger also steps into importlib, if one steps 'into' an import statement. Most of the time, this is a nuisance. If one is importing from one's own module, stepping over 'import mymod' is not a satisfactory way to avoid this. Perhaps we should add '(X) Step past IDLE internals' and '(X) Step past Python internals', both on by default. 'python internals' would be builtin features that happen be implemented, at least in CPython, in python rather than the internal language. Other ideas: a drop down skip list with items checked. Or a general policy of skipping Lib/* with a list of exceptions.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-IDLE type-bug An unexpected behavior, bug, or error
Projects
Status: No status
Development

No branches or pull requests

1 participant