Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

this can be potentialy asynchronous... will asynchronous version be created #49

Open
07pepa opened this issue Aug 7, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@07pepa
Copy link
Contributor

07pepa commented Aug 7, 2022

No description provided.

@billdeitrick
Copy link
Owner

billdeitrick commented Sep 2, 2022

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.

@07pepa
Copy link
Contributor Author

07pepa commented Sep 5, 2022

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)

https://www.python-httpx.org/async/

@07pepa
Copy link
Contributor Author

07pepa commented Sep 5, 2022

also i see it like this types and testing them even internaly (bigest pain)

then maybe optional converting to clases

then async

@billdeitrick billdeitrick added the enhancement New feature or request label Sep 6, 2022
@billdeitrick
Copy link
Owner

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).

@07pepa
Copy link
Contributor Author

07pepa commented Sep 6, 2022

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%

@07pepa
Copy link
Contributor Author

07pepa commented Sep 23, 2022

this will take longer then expexted kevin1024/vcrpy#656

@07pepa
Copy link
Contributor Author

07pepa commented Sep 24, 2022

and there is fix for pyvcr it is currently a blocker kevin1024/vcrpy#657

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants