Give name from assignment higher precedence than label

[jgosmann]

Currently, the label for a Nengo object will have higher precedence than the name determined from assignment. For example:

with nengo.Network(label="this name is used") as not_this_one:
    also_not_this_one = nengo.Ensemble(10, 1, label="this name is used again")

However, many Networks in nengo_spa have a default label which is not very specific. In those, cases it would be beneficial to use the name from the assignment:

use_this_name = spa.State(64)  # Actual name will be "State"

I currently cannot think of any situation where the proposed behaviour would be undesired. If a name from assignment can be found, it usually will be more specific (because it should be unique in the scope, or if not the name will be used for only one of the objects anyways). If no such name is found, the name can be set via the label as before.

[tcstewar]

I currently cannot think of any situation where the proposed behaviour would be undesired.

The one that comes to mind for me is that I've often wanted to set label in order to directly control what the GUI displays, for purposes of making demos or screenshots for papers. I'd like to maintain that functionality, if possible...

But I definitely agree that the default labels in nengo_spa aren't very specific. One other possibility would be to remove the labels from nengo_spa, if they aren't specific enough to be useful....

[jgosmann]

That would lead to even less specific labels in other situations as many objects in expressions are not assigned to a discoverable variable.

[tcstewar]

That would lead to even less specific labels in other situations as many objects in expressions are not assigned to a discoverable variable.

Hmm.. so why not only set labels on things that aren't assigned to discoverable variables?

[jgosmann]

Because there is no way (except maybe some fragile introspection) to know what gets assigned to a variable when the label is being set.

On December 7, 2018 1:31:37 PM GMT+01:00, tcstewar notifications@github.com wrote:

That would lead to even less specific labels in other situations as many objects in expressions are not assigned to a discoverable variable.

Hmm.. so why not only set labels on things that aren't assigned to discoverable variables?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nengo/nengo-gui/issues/1000#issuecomment-445219042

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[tcstewar]

Because there is no way (except maybe some fragile introspection) to know what gets assigned to a variable when the label is being set.

Hmm.... fair enough. That said, I'm not sure that's a strong enough reason to make it impossible for someone to manually set the labels on the nengo-gui display, which is the use case I mentioned above that I do fairly frequently. Do you see any way of handling both cases, or are they mutually incompatible?

[tcstewar]

(I'll also note that "fragile introspection" is pretty much exactly what nengo-gui does to discover those labels, so it might be okay for nengo_spa do do that as well.... )

[tcstewar]

Oo, I just thought of another idea -- you could add them to a discoverable list within the Network.... something like model.bind[3] which would show up as bind[3] in nengo_gui.....

[jgosmann]

Do you see any way of handling both cases, or are they mutually incompatible?

They are probably incompatible without some sort of workaround. Currently, the workaround is:

x = spa.State(32, label='x')

Maybe it is worth considering to instead have some sort of workaround for setting a different name when the variable takes precedence.

(I'll also note that "fragile introspection" is pretty much exactly what nengo-gui does to discover those labels, so it might be okay for nengo_spa do do that as well.... )

Well, I believe so far we only look into the object attributes and locals dictionary. That is still pretty harmless. The introspection I meant here requires to go through stackframes get the code for the calling lines, parse it into an AST (which might not possible without the context around the line), find the correct assignment (there might be multiple in one line). All of that seems to be a magnitude more fragile.

you could add them to a discoverable list within the Network.... something like model.bind[3] which would show up as bind[3] in nengo_gui.....

That would add undesired side effects. If I type:

x * y >> z

I don't expect it to set something on my model (except modifying the Nengo object lists), which might even collide with user-defined attributes.

[jgosmann]

One potential solution I see is to not set labels for the SPA networks and use the class name in Nengo GUI. The precedence would be something like: label, variable/attribute name, class name. However, Nengo GUI currently looks at the Nengo object lists (networks, ensembles, ...) which would be higher in the precedence. So an exception for at least the networks list is required.