Exposed _handle_from_node_name dict via method

[lstoex]

Would be nice to access node handles on a name basis, similar to meshcat. As such, I exposed the internal _handle_from_node_name dict via a method that returns either the handle or none, if the name wasn't found. Ideally this would be extended to allow for wildcard matching of entire groups of handles that follow a defined pattern.

[brentyi]

Hi @lstoex, thanks for the PR!

We've considered adding features like it a few times, but have decided not to so far. Reasons are a combination of:

• Reducing the number of different ways to do the same thing (even if the current way of creating a lot of variables is annoying sometimes)
• Bias against APIs that aren't type-safe (both the string input and the handle output)
• Effort needed to make sure handle_by_name() behaves consistently, eg it always returns None when a node doesn't exist
  • I'm not sure we're very rigorous about cleaning up the _handle_from_node_name dict when nodes are removed (for example: when its parent is removed, or if a node is added via a client-specific scene API but then the scene is reset from the server's scene API). Which is somewhat defensible since the dict isn't part of the public API, but that would change with a method like the one proposed in this PR.
  • These things are minor but since the method itself is an optional QoL addition I'd prefer to avoid accruing [more] unclear or inconsistent edge case behaviors.

Curious about your thoughts. I see why the helper is convenient and I want to consider it, unfortunately have too much on my plate right now though, will try to come back to this in February!!

[lstoex]

Hey, thanks for the swift reply! I can see why you would not want to introduce an 'unreliable' feature.
Coming from Meshcat, I have found it convenient to add objects as I go, adhering to some system of names. Then, you could go back to groups of geometries simply by traversing the name trees. This made it very understandable (for me anyways, haha) and allowed me to do initially unplanned things with minimal refactoring. Keeping lists of handles, of course, isn't too much to ask for, just thought it might be helpful for quick prototyping/research.