It’s a very simple suggestion. In IDLE, display id in Debug Control window.
Welcome to DPO! Is there a particular reason for this suggestion? There’s a very large number of things that could potentially be displayed in any given window; if you want this idea to move forward, you should explain what the idea would add, such as describing use cases or demonstrating widespread interest.
What id? PID?
- In Python, variables exist in different namespaces and variables from one namespace can be accessed in a different namespace.
- Besides this, parameters are passed to functions as “copy of object reference”.
- Python, by dynamic typing, makes it easy to confuse what object a variable is bound to.
- The simple assignment statement
x = y
creates an additional alias of an existing object variable.
- To keep track of which object in memory a variable is bound to, the simplest and most direct way is to look at the id of the object, accessed via
id(x)
This is a big help in debugging programs where keeping track of objects can get confusing for the above reasons.
Hence, along the variable name x, display it’s id id(x) in the IDLE Debug Window.
The id of a variable.
The id I’m referring to is the one accessible from the command line by typing
id(x)
for a variable x.
Please explain how the object id would be of any use for debugging. Can you give an example? Is there any precedent in other debuggers? Does the text-based pid do this?
I am a beginner in Python. IDLE is the only Python debugger I have used so I cannot say how other debuggers handle this.
From what I know, pid (retrieved from os.getpid()) will NOT provide any information relevant to this issue.
Consider the case where programmer tries to clone a list. Further on in the program, he compares elements in the lists for equality. Since cloning in Python creates a shallow copy, this leads to a logical error which falsely returns True.
x = [1, 3, 5]
y = x[:]
for i in range(len(x)) :
if(x[i] == y[i]):
print("Same") #Logical error
Debugging this error can be assisted if programmer can view id(x[i]) and id(y[i]) in the Debug Control window, which will tell him that he is comparing the same object against itself.
What is the logical error here? It feels as if you’re making some false assumptions about python, because this comparison is absolutely something you should expect will be true.
Moving this to Help instead of Ideas, as this has turned into help understanding Python’s data model rather than a well developed idea to discuss.
1 Like
The corresponding items should compare equal whether the same id or just copies. But I am ignore this.
I am the prime IDLE maintainer, have worked on the debugger, am glad you tried to use it, and intend to improve it further. Your request gave me an idea and I opened a draft issue on the IDLE project list of issues.
Using your code as an example, the following gives two current solutions and a proposed third.
Stepping thru ‘if’, debugger stops on ‘print’. Suppose user wants to see id(x[0]), id(y[0]).
(The reason does not matter.) Current solution with debug print and debugger code.
- Put
xi, yi = x[i], y[i]; print(xi, yi, id[xi], id[yi])above print and run without debugger. - Put
xi, yi = x[i], y[i]; xid, yid = id[xi], id[yi]above print and run with debugger.
Values for the 4 variables will be displayed.
Proposed solution 3, without editing file, implemented in steps to ease development:
A. Add eval feature so user could put expression is a box using listed variables with complete literal values.
If debugger has those literals as strings, not objects, evaluate the strings first so literal could
could be evaluated locally. Example expression for example code: (xi:=x[i]), (yi:=y[i]), id(xi), id(yi).
Note use of parenthesized assignment expressions to capture values for later use.
B. Put expression and result in a new ‘Expressions’ box and re-evaluate at every stop, caughting all errors.
C. Send expression to user process, allowing use of all variables, including functions.
I believe that if debugger lists myfunc <function myfunc at 0x00000182E949D7A0>, it has only the description, from the user process, and not the executable. Hence the need to execute where defined.