Repository navigation
IDLE: disable edits of debugger local/global vars that are not propagated. #69184
Description
| BPO | 24996 |
|---|---|
| Nosy | @terryjreedy, @kbkaiser, @serwy, @roseman |
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 2015-09-03.21:29:13.919>
labels = ['expert-IDLE', 'type-bug', '3.10']
title = 'IDLE: debugger local/global vars should not be editable'
updated_at = <Date 2020-06-06.22:31:20.243>
user = 'https://github.com/roseman'bugs.python.org fields:
activity = <Date 2020-06-06.22:31:20.243>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2015-09-03.21:29:13.919>
creator = 'markroseman'
dependencies = []
files = []
hgrepos = []
issue_num = 24996
keywords = []
message_count = 5.0
messages = ['249690', '249694', '249697', '249703', '296375']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'kbk', 'roger.serwy', 'markroseman']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue24996'
versions = ['Python 3.10']Metadata
Metadata
Assignees
Projects
- Status
Activity
roseman commentedon Sep 3, 2015
In the debugger, the values for the variables shown in the locals/globals panes are editable (i.e. using Entry widget) but I don't see any mechanism to have those changes affect anything. If I'm not missing something, why Entry and not Label?
terryjreedy commentedon Sep 3, 2015
I already brought this up as part of one of the StackViewer/Debugger/merge issues. Replacing the list with a tree would automatically change this unless the tree was changed to have a entry. Why? My speculation is an intention never carried out. Labels could be made to look different, so that cannot be the reason. Can a ttk Treeview allow entries in a column, in case we ever wanted to make changes propagate?
roseman commentedon Sep 3, 2015
Thanks Terry, sorry I missed your previous mention of this. From what I recall the treeview doesn't allow editable items, but what I've done in similar circumstances before (editing text items on a canvas in drawing type programs) was 'place' an entry widget on top of it at the right location as needed and then get rid of the entry when done, which provides the correct effect.
You know what, I think I know why they might have used an Entry widget... for really long values of variables the entry can stay a fixed width and will horizontal scroll, but a label will expand to the size of the content
terryjreedy commentedon Sep 4, 2015
That makes sense, given that a string or list could be indefinitely long.
terryjreedy commentedon Jun 19, 2017
I believe an Entry validator can reject all keystrokes.
It seem feasible that globals could be changed. I could look at what pdb can do and if so, how.
ncoghlan commentedon Aug 1, 2024
Given that PEP-667 makes it possible for IDLE to reliably edit both local and global variables, is this issue still valid?
[-]IDLE: debugger local/global vars should not be editable[/-][+]IDLE: disable edits of debugger local/global vars that are not propagated.[/+]terryjreedy commentedon Aug 1, 2024
Currently, editing a value string in the debugger window in the IDLE process has no effect on the object value in the execution subprocess. This issue was about blocking edits in the window until we add a mechanism to propagate edits of sensibly editable values, such as strings, numbers, and collections thereof to the subprocess. Some values, such as dunders and classes, cannot or should not ever be edited. When Mark opened this issue, we only considered the possibility of propagating (appropriate) global values, which would only be useful in special cases, and hence not terribly inviting. Being able to edit function locals should make such an effort worthwhile.
terryjreedy commentedon Aug 1, 2024
While retesting current behavior, I discover a glitch in update timing. Start IDLE Shell and Debugger and show globals. Shell is active, accepting input, and Debugger actions buttons are not, as there is no code to act on. Enter
a = 0\n. Shell input is frozen and Debugger buttons activated with the enter code displayed. Hit go and the code is executed, Debugger inactivated, and Shell unfrozen. But the globals display does not show the new variable and value. Enter code, possibly empty and Shell input is frozen and Debugger activated with variable display refreshed, showinga 0. When a file is run with debugger, the effect of the last statement executed is not shown unless one enters something in Shell. Either way, globals and locals should be updated after execution before inactivation. Similarly, if we propagate edits done in a separate widget (somewhat likely), the displays should be updated from the execution process.serhiy-storchaka commentedon Sep 6, 2026
#157029 replaces the canvas of labels and entries with a read-only two-column table, so there is nothing left to type into. A long value still does not stretch the pane, since the column has a width of its own — Mark's reason for the entries in the first place.