fixes #121 and fixes failing tests due to endpoint error

[ayushanand18]

Overview

• fixes #121 by including **kwargs in resource fetching, and
• fixes failing tests due to 400 error at endpoint by using a trivial approach of picking the first occurrence id of all records.

Changes Introduced

• All module methods have been updated with kwargs acceptance. args -> {**args, **kwargs}
• Change failing occurrence.get() test to fetch the first record's id in occurrences.get(id=occurrences.search(size=1).execute()['id'].values[0]).

Thanks!

[7yl4r]

I am confused about the syntax here. Why this:

return ChecklistResponse(url, {**args, **kwargs}, paginate=True)

instead of this:

return ChecklistResponse(url, paginate=True, *args, **kwargs)

I think you may have overtaken my python knowledge already. :sweat_smile: .

[7yl4r]

I have been looking more and understanding better... I am going to write this all out to be sure.

{**args, **kwargs} splats two dicts into one dict. Part of my confusion was that args here is a dict formed in the function, not the typical args usage.

Consequences:

(1) kwargs win in collisions

When there is a collision in this shorthand dict union the second one (kwargs in this case) wins:

>>> {**{'a':1, 'b':2}, **{'a':2, 'c':3}}
{'a': 2, 'b': 2, 'c': 3}

I think this is a non-issue because kwargs will never contain a known arg.

(2) typos & bad parameters

When a bad kwarg is passed to the function it will propagate to the API. The API will either ignore the bad param or throw a 500 error. This is probably fine; we can add some more clever handling once someone reports being confused by it.

---

Other thoughts: what is the benefit of keeping any of the args? It is helpful to have the documentation, but perhaps we should just be pointing to api.obis.org for that information?

[ayushanand18]

Thank you so much for the great observation. I want to summarize my chain of thought behind this implementation.

• As you noted it correctly that the args are different from the default args which we generally have in methods. args is a local dictionary being created based on the input arguments. I second with your conclusion in (1) that it won't be an issue in any situation because args will automatically pick the arguments who's parameter has been defined in the parameter list. args and kwargs will be different in each case.
• From my observation OBIS API completely ignores non-existent arguments (or bad kwargs) while executing the query.
• On the benefits of keeping parameter list, it really helps a user when they are using the package with automatic suggestions for parameter name. Many users might be using pysense or a similar tool or maybe supported by their local IDE (even Google Colab supports it). So, it maybe a Saviour and not lead users to go back-and-forth with the package docs or API docs.
• I believe that keeping some arguments out of args list would be good because the OBIS API can undergo some rapid changes on lesser used arguments. There keeping a list of commonly used args would make sure obsolete arguments do not propagate longer.
• It is because of the manner in which we execute the GET request that I preferred this dictionary concatenating approach over passing it as another argument.

I'm open to your thoughts on this.

[7yl4r]

Thank you for the added information; everything sounds great.

Thanks for your awesome continued support!

[ayushanand18]

Thanks a ton! I'll continue to do so as long as I can find time :)