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
The main motivation for this is that in the current API in order to update an item, one has to supply all its keys - there is no motive for all the keys to have to be in order.
Using frozenset should also be more efficient, but those gains should be marginal.
However, this change could break some backwards compatibility for the "get_other_keys" method if someone is expecting the key order to be maintained there (however, there is no such order promise, since the result for that function is a rebuilt list, not the key-tuple currently used as key) - I think the return type for it should be a frozeset instead of a list as well.
The text was updated successfully, but these errors were encountered:
The main motivation for this is that in the current API in order to update an item, one has to supply all its keys - there is no motive for all the keys to have to be in order.
Using frozenset should also be more efficient, but those gains should be marginal.
However, this change could break some backwards compatibility for the "get_other_keys" method if someone is expecting the key order to be maintained there (however, there is no such order promise, since the result for that function is a rebuilt list, not the key-tuple currently used as key) - I think the return type for it should be a frozeset instead of a list as well.
The text was updated successfully, but these errors were encountered: