You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see what you are doing with Keybinding, and trying to make it magically work with strings, but I think it's a footgun in the long run.
What I Did
In [1]: from app_model.types import KeyBinding
In [2]: X = [KeyBinding.from_str('A')]
In [3]: [isinstance(s, str) for s in X]
Out[3]: [False]
In [4]: 'A' in X
Out[4]: True
For me Out[3] logically implies that In [4] Cannot be True. And equal but hash is different is a footgun as well:
In [7]: d = {}
In [8]: d[X[0]] = 1
In [9]: d['A'] # must be 1 as X[0] == 'A' ?
No KeyError.
I think this is make worse by the fact that __str__ return the keybinding in the string form as now code in napari liberally use the object directly in places where it's implicitely str()'d.
The text was updated successfully, but these errors were encountered:
I'm open to changes if you want to open a pr for discussion
Thanks, I'll try to thinking how we can try to be stricter, and have a path forward with backward compatibility. I'll see if I can incorporate as well some of the logic we have in napari to display platform specific symbols for shortcuts.
Description
I see what you are doing with Keybinding, and trying to make it magically work with strings, but I think it's a footgun in the long run.
What I Did
For me
Out[3]
logically implies thatIn [4]
Cannot be True. And equal but hash is different is a footgun as well:No
KeyError
.I think this is make worse by the fact that
__str__
return the keybinding in the string form as now code in napari liberally use the object directly in places where it's implicitelystr()
'd.The text was updated successfully, but these errors were encountered: