1

Resolved

What items should be shown in the VS Locals window?

description

I invite discussion about which items you would like to see or not see in the Locals window while debugging a script; this would include expansions of items in the Watch windows. I am also proposing some changes myself.
  1. Might there be some options in the Locals window as to categories of items to show?
  2. When expanding an instance, attributes which themselves have a __getattr__ or __call__ method are not shown. I propose that items in the instance dictionary should always be shown. Items in the class dictionary might be filtered, but I would like to exclude only actual function objects (which are then methods of the instance) and types or classes. This relates to Issue number 2019.
  3. An alternative proposal would be to have a separate item for the class, which would then expand to show class attributes (including base classes, nested classes and methods); in this case, no class attributes would be shown directly under the instance. Also, the item should be distinguishable as the class of the instance, rather than an attribute of the instance that happens to have the same name
  4. At the top level, I see names of attributes which are mentioned somewhere in the current stack frame. These always are shown as 'undefined', unless they also happen to be local variables. This is a bug, IMHO.
  5. I propose some way to see global variables. Perhaps an item at the top or bottom of the Locals window called <globals> which could be expanded. This expansion would include imported modules, which could themselves be expanded.
  6. [edit] A class object does not show nested classes. This is just another case of a child that has a __call__ method. If the class has no class attributes other than nested classes, then trying to expand the containing class results in the + sign disappearing, which made me originally call this a bug.
  7. A dictionary member whose key is a user-defined type instance (as opposed to an int or str, for instance) does not expand. [edit] I have filed this as Issue 2074.

comments

pminaev wrote Jan 2 at 8:09 PM

It is possible to add menu items to the context menu that shows on Locals/Autos/Watch windows (it's the same one for all of them), but that is the extent of our ability to customize the UI. So simple on/off or radio button style options can be implemented, but not advanced filters based on text input and such.

With respect to how attributes are shown, what we do is basically dir() the object, and then filter out all the magic __...___ stuff, and also all items which have a __call__. As #2019 mentions, this is so as to filter out methods, which are not particularly useful on instances (in fact, I would dare say that showing them on classes would probably be more useful than showing them on instances). You're right though that we should probably rather be filtering only actual function/method objects, and not just everything that happens to be callable.

dir() is where the class attributes come from. The advantage of using it is that it will correctly account for any kind of custom __getattr__ and __getattribute__ implementation. I'm not sure how to properly filter out class attributes - it cannot be done by name alone as the object can have its own attribute with a matching name but different storage.

<undefined> locals is by design - we show all names that are used in the frame (basically, co_names of the code object). This can be handy if you want to add a watch on that variable in advance, for example. But perhaps this should be configurable - I can imagine it getting unwieldy in large functions with a lot of locals, some of which are specific only to one branch of the function.

Global variables that are referenced by the current frame should show up among the locals. There is no convenient shortcut to see all globals, but note that you can add a watch for globals() in the Watch window. At the same time, we do have a [Globals] node in the Locals window in mixed-mode debugger, which works exactly as you describe, so this is something that we should consider doing for the sake of feature parity.

The last two items are definitely bugs. Can you please file them separately for more convenient tracking of each one?

pminaev wrote Jan 10 at 9:50 PM

I've created a separate work item to track the bug # 4:
https://pytools.codeplex.com/workitem/2085

pminaev wrote Jan 16 at 7:08 PM

Separate work item for # 5:
https://pytools.codeplex.com/workitem/2092

pminaev wrote Jan 16 at 7:09 PM

I'm resolving this one as all items are either tracked by their separate issues, or resolved with my latest checkin (it's not on CodePlex source tree yet, but will be soon).

mrolle wrote Jan 17 at 7:49 AM

Thanks :)