Consider using delphi-epidata python client lib

[melange396]

The pip-installable delphi-epidata python client has matured in the recent past, and it continues to improve and add features. Consider using it as a foundation for this library, and build upon it here instead of duplicating its functionality.

With this approach, the delphi-epidata python client can be responsible for network/transport and syntactic concerns (which includes things like handling retries, caching, authentication, decoding responses, handling hostname or path changes, etc), and epidatpy can focus on statistical/analytical methods and data semantics.

There will be less work because there won't [always] be a need to update two separate client packages when API changes happen, and it will keep the server side changes in the same place as the low-level client side changes for compatibility with them.

[dshemetov]

I like this idea. Like you said, that library (I'm gonna call it delphi-epidata.py here) can stay focused on query param validation and network stuff, while this library (epidatpy) can handle converting the response to a type-correct Pandas DataFrame, data caching, and ergonomic things like signal name autocomplete. From my initial look at delphi-epidata.py, this seems feasible.

Before we commit to a full migration and rewrite of epidatpy, we should try prototyping this idea with a few endpoints. Some things to note in this experiment:

• does query param validation in epidatpy and in delphi-epidata.py work well? (I'm thinking of things like date or int or string inputs for the date variable). It would be less than ideal to have some validation here, some validation there, some type coercion here and some there. We should pick one place and focus on handling that there. Since the delphi-epidata.py already does some of that (see here), it seems natural to just continue to keep it there
• if in the process of doing the above you make changes to delphi-epidata.py, does those changes feel restricted by existing usage in acquisition/server?
• do we really need async requests? Do we need to support async requests? #30
• maybe more