Open 07pepa opened 2 years ago
yeah but i do not know if synchronous version should stay or should be converted
othervise i will likely use this ( it support trio any io and asyncio (curio unfortunately not)
also i see it like this types and testing them even internaly (bigest pain)
then maybe optional converting to clases
then async
We need to keep the synchronous calls in place to avoid breaking backwards compatibility. My preference with adding async support would be for the synchronous calls to simply become wrappers to async versions of the same calls, and then existing code will continue to work with the option to use async calls as desired.
I think I would like to see async support added before object serialization/deserialization, but we can be flexible there.
I haven't used httpx before, but from a quick read it looks like that would be a good choice. I like the API feels similar to requests and it also has VCRPY support (I would consider this a hard requirement).
ok i am fine with async going 1st as well
i think i will do a mirror image of curent api that will be async and wrap it
someting like this
import asyncio
class PCO:
#... store async version in self and current (created) asyncio loop in self
def get(self,<PARAMS>):
return self.loop.run_until_complete(self.async_pco.get(<PARAMS>)) # should be thread safe but documentation does not specify
this should be simplest way with no other dependency just httpx and dropping requests
and current test will stay and will not double and cov still will be 100%
this will take longer then expexted https://github.com/kevin1024/vcrpy/issues/656
and there is fix for pyvcr it is currently a blocker https://github.com/kevin1024/vcrpy/pull/657
An async version would be fantastic. I don't have sufficient margin to do this immediately, but would happily accept a PR as per my comments in #48.
I would anticipate having the time to work on adding async support in early 2023.