-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add limit= to get methods, make their signatures more uniform #15
base: master
Are you sure you want to change the base?
Conversation
Thanks! I planned to wrap the rpc enums in custom enum types, like one from watch commands. |
Please see https://github.com/martyanov/aetcd/blob/master/aetcd/rtypes.py#L257 for example. I personally don't like the string literals here, pretty much easy to abuse. |
Can probably be fixed in a follow-up commit or PR. |
c6e863c
to
42bc33b
Compare
Added new enums for ordering in the second commit, a couple notes on those:
|
Why not just Not sure if I like the I'll take a closer look. Thanks! |
A little follow up. If you make the enums importable via |
They are only relevant for RangeRequest and translated to RangeRequest.SortOrder, so seemed fitting to namespace them like that, similar to how EventKind is not just Kind, but obviously doesn't really matter. |
Yeah, I think with strings I was also a bit influenced by how EventKind is halfway str + enum type. Guess if enums are fine, should get rid of all "str" in there and only ever use/allow enums. |
Yep, but only the enums should be explicitly imported, as other types return implicitly as operation results, so they only needed may be for type annotations. I think the short enum names are self descriptive enough, readability counts. And we dont have many of them in proto definitions. |
Enum-only variant sounds good to me. |
87c1a12
to
aa7e17a
Compare
EventKind, SortOrder, SortTarget should be all auto-value enums now, with None or str passed to sort_order/target options raising ValueError. |
aa7e17a
to
3bc9e7b
Compare
Adding one missing request parameters, one key at a time...
Ordered keys to be more like rpc.proto, maybe e.g.
get_range(self, range_start, range_end, *, ...)
in all sigs can be used to avoid such ordering/additions ever breaking code in the future, but guessing it's not an issue atm anyway.Added docstrings for couple parameters where they were missing, but dunno how these should look for sort_order and such enums, so skipped these here.
get_all() was missing type annotations.