Implement API features about python-etcd3 HOT 4 OPEN

Unfortunately KV implementation is not feature-full yet.
Response on Range request must return not only values (and keys) but all available meta-data (create_revision, mod_revision, version, lease) together with ResponseHeader, otherwise it is not possible to implement something more complex than a child-toy app listing keys and values... :(

Also I think KeyNotFoundError exception should be to raised only for get(key) methods, but not for get_prefix and get_all (it is kinda OK to have an empty ranges).

from python-etcd3.

Yeah, this list is mostly about which parts of the gRPC api have been implemented, not which parts have a finished publicly facing api.

About the KV stuff, I started #53. Feel free to write your thoughts there.

from python-etcd3.

New to this repository and contributing in general and hoping to get into it with smaller feature additions. Do you think that adding a contains feature would be useful to determine whether or not a key is contained within an etcd instance? I understand it's quite trivial to check but it would make for a more complete KV api.

from python-etcd3.

@akuchibotla exists(key) might be useful, although it's generally easier to check if get(key) returns None.

If you want something small to work on, you could implement Hash? (https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_reference_v3.md#service-maintenance-etcdserveretcdserverpbrpcproto)

from python-etcd3.