highlight variable if it was changed about pudb

[asmeurer]

I'm looking at implementing this. One question is how to determine if a variable has changed. The obvious way is to use old_var_value == new_var_value on each variable, but this is potentially expensive or even dangerous (remember that __eq__ can do anything in Python).

Another option would be to only compare if the stringified value of the variable has changed. The disadvantage here is that if you use the default string value, type, then if a variable changes but its type doesn't (e.g., adding a new key to a dictionary), then it won't be highlighted. If we do this, then I think we should also add a mechanism to cache the stringified value so it is only computed once per step.

Is it possible to use the debugger to somehow tell what variables should have been changed (e.g., through assignment or by running through the top of a loop)? Obviously, that wouldn't catch everything, such as manually setting keys in the locals() dict, or even "magic" functions that inject names into the namespace. But this could also open possibilities for things like caching stringified values and only updating them when the variable is updated, which should make stepping a much faster process.

[asmeurer]

Actually, I guess is comparison should work. I'll try it and see.

Either way, I'd still like to hear your opinion on caching string values and only updating them when the variable is "updated". I do like using the str stringifier (actually, my custom one in the example file), but it can be expensive sometimes when working with large objects.

[asmeurer]

OK, I misunderstood how things work above. I think I have a better view of it now, though. == or is won't work, because the old object is simply not kept around.

So I think the real options are these:

• Compare stringfied forms, as I suggested above.
• Somehow hook the bdb debugger to keep track of what locals are changed. I think this could be achieved by replacing the locals dict with a custom dict subclass that marks new items. I haven't done much with Bdb, so I don't know how hard that would be to do. It didn't seem obvious how to do it with our current use. I also don't know if this would generalize nicely to highlighting changes to "sub-variables" (what you get when you press \ on an object).

By the way, something that would be real easy to do (or at least relatively easy), would be to just highlight new variables. I can implement this behavior right away, but I'd like to wait and see what the best way to highlight changed variables is, so I don't end up writing something specialized and then tossing it.

[nedbat]

I think "is" isn't sufficient anyway. If I have a dict variable, it is "changed" if I add a new key to it, or change a value of an existing key. But it still "is" the same dict. What if my dict has a list value, which is a list of dicts, and one of those dicts gets a new key? Has my top-level dict "changed"?

I'm not sure there's a definition of "changed" that meets the two necessary criteria: 1) corresponds to what people mean when they say "a variable has changed", and 2) can be computed conveniently by pudb.

[asmeurer]

Unless we can somehow hook the locals dict as I suggested above, I would just go off of the string form. It won't be useful if you don't use str and there will be false negatives, but I think it would still be useful. We would probably need to add a note next to the option to make it clear that this is how it works, though.