I have seen it before starting my project. I had issues with the dynamic codegens (for example, last time i’ve tried the swagger spec with the online generator on swagger.io it was complaining about not being able to generate something under Assets; on another online generator, the python code for validating the character type (from get_characters_character_id) was testing “if security_status” instead of “if security_status is not None”, which failed when sec status was 0.0). Being weary of them was what threw me off from EsiPy before trying it.
But I didn’t expected a reply from its author 
. I will give it a try.
I agree. My intention was to be able to supply my own RESTClientObject to the swagger_client which would make use of a cache object.
In the end it didn’t work as I’ve intended since RESTClientObject returns (among other stuff) a urllib3.HTTPResponse, which does not serialize 
I’ve implemented a variation of swagger_client.ApiClient which is cache aware (it just overloads the call_api and makes use of a cache class) respecting the headers sent from ESI.
I will give a shot to EsiPy and compare how easy is to write a simple project compared with the swagger-codegen generated code.
Just as a side note, as I’ve read a bit of EsiPy source and you are also using diskcache: I was not too found of it using pickle. If you use an external DB and don’t secure it properly, it is possible to inject arbitrary code “pickled” in the DB to be executed by your app. I’ve tried to store my cache in json but it made my life miserable.
My intent on providing a cache class to such “low level” in the api client was to attempt to cache the raw responses from ESI before they get parsed by the client, so I don’t get into serialization issues but in the end (to accomplish this) might be easier to just write/use a HTTP proxy instead.