Implement a better check for hidden values for %who etc.

[takluyver]

From discussion in #4076, this uses a dictionary for hidden values instead of a set, and checks identity as well as name.

In [3]: e = 5

In [4]: f = 6

In [5]: %who
e    f   

In [6]: %whos
Variable   Type    Data/Info
----------------------------
e          int     5
f          int     6

[minrk]

Is there any concern about the extra caching, since we are storing the objects themselves, rather than just their names?

[minrk]

If there is such a concern, I suppose it could be a dict of id(object) instead of the objects themselves.

[takluyver]

We're storing another reference to objects that already exist, so it shouldn't be any more memory use in the standard case where you keep all those names around. Caching ids might be problematic, because if an object does get destroyed, its id (which is just a memory address, at least in CPython) may be assigned to another object, so we could end up inadvertantly hiding things that should be displayed.

[minrk]

We're storing another reference to objects that already exist

Yes, but they can be deleted. With this change, shadowed objects will never be deleted. I'm mainly wondering if that's ever going to be an issue.

we could end up inadvertently hiding things that should be displayed.

The only case that can effect is an object in hidden_ns is deleted, and then a new object is created interactively with the same name and at the same address and in the hidden_ns. That seems sufficiently unlikely to be ignored.

[takluyver]

I doubt deleting objects will be a big issue - this is mainly for pre-importing stuff, in which case it's loaded in with the module even if it's not assigned to a name in the interactive namespace.

The only case that can effect is an object in hidden_ns is deleted, and then a new object is created interactively with the same name and at the same address and in the hidden_ns.

If you reassign to an existing name, it would normally create the new object before it deletes the old one, but I don't think that behaviour is guaranteed, so a compiler optimisation could make it delete the old object first and then create the new one in the same piece of memory. I agree that this is not a big concern, though.

[minrk]

Okay, then I think this is good to go.