Open melange396 opened 5 months ago
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:
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 theredelphi-epidata.py
, does those changes feel restricted by existing usage in acquisition/server?
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), andepidatpy
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.