Plans for future updates

[lavagetto]

Hi all!

I thought I might spend 10 minutes to write down some ideas on how to evolve the library now.

Deprecation of old methods

We have quite a few methods that are a leftover of the first version of the client, and that are now nothing more than aliases for the base methods.

I would like to reduce the API surface and deprecate those methods for now, and remove them in a later version

V3 support

While I know there is a v3 python client that works decently, it has a couple of issues:

• It doesn't have the fault tolerance that python-etcd has
• Its API is very different from the one we have here. While I agree that not everything should be 1:1 with the current API, I personally find it very irritating to have to rewrite all of my code to transition to use etcd3.
• python-etcd is a standard and it's already packaged in a few linux distros, it would be nice to have support for etcd v 3 for python in the distributions easily.
• I am unsure if this should be a small compatibility layer on top of the existing library or a new implementation. I'm honestly thinking of the latter, as I already wrote a semi-complete client implementation some months ago and never found the time to finish it.

What do people think? Other things that would be useful?

[SamuelMarks]

It may be as simple as creating a v2 shim—always printing a deprecation message when it's is used—which could be rather trivial, something like:

def _all_get(key, **kwargs):
    return namedtuple('Val', 'value')(self.get(key)) if self.protocol == 3 else self.get(key)

[r0h4n]

Do we have etcd API v3 support? Kinda confused looking at the comments

[virtualsafety]

Do we have etcd API v3 support?