-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get 'None' or a default value if key does not exist #56
Comments
You'd prefer something like this? >>> import etcd3
>>> etcd = etcd3.client()
>>> etcd.get('not-a-key')
(None, <etcd3.client.KVMetadata object at 0x7f5e32621790>)
>>> etcd.get('not-a-key', default=b'toot')
(b'toot', <etcd3.client.KVMetadata object at 0x7f5e32621650>) |
I would indeed, I think it would allow to write more concise code in most situations. What do you think ? |
Official etcd2 client throws exception when key is not found, I would prefer current behavior. Current implementations can simply switch type of Exception handled without modifying logic around client. |
There is no official Python client for etcd, just third party libraries referenced in the documentation - as this one is. If you take a look at the behavior of the go etcd client for v3 API (which is the only one maintained by CoreOS as part of the project), it returns a data structure as part of the response (resp.Kvs) which is empty if a key is not found, and the error returned by the .Get method is 'nil' in this case. |
I'd mimic the behaviour of dict: raise KeyError (or a subclass thereof containing the KVMetadata object) if a non-existent key is accessed without providing a default. To check if a key exists Disclaimer: I've never used etcd nor this library. |
Addressed by #73 |
Hello,
Thanks for working on this. I've just started using etcd v3 so maybe I'm missing something, but I find that the default behavior of the client's 'get' method when requesting a non-existing key is inappropriate. I think we should take advantage of a behavior similar to the Python dictionary, i.e. be able to get at least 'None' instead of catching an exception.
This is especially true when we want to test if a key already exist. Moreover, it would be more consistent with the 'etcdctl' CLI tool that does not display anything when a non-existing key is requested, an return a 0 exit code.
The text was updated successfully, but these errors were encountered: