add: Trio support via AnyIO #183
Conversation
|
Hey @thearchitector, Thanks for your contribution! Could you tell me please what is the benefit of using anyio or adding the trio support? I'll be honest, I'm not that deep into Python world and hence this is the first time I'm hearing about them :) Thanks! |
|
hi so normally people using trio can't use libraries that are asyncio specific anyio makes this a bit easier by allowing us to use both libraries tho if there's gonna do more async development i suggest we also think about the problem we encountered with type hints (I'm on a phone so it's hard to link, sorry) |
tests/test_asyncio/conftest.py
Outdated
| @pytest.fixture | ||
| def anyio_backend(): | ||
| return "asyncio" |
There was a problem hiding this comment.
it should test against trio as well
There was a problem hiding this comment.
yeah very much WIP, planning on cleaning stuff up before un-drafting
| print(repr(pool)) | ||
| # print(repr(pool)) |
| _grl: Any = asyncio.get_running_loop, | ||
| # _grl: Any = asyncio.get_running_loop, | ||
| # _sniff: Any = sniffio.current_async_library, |
| try: | ||
| context = {"client": self, "message": self._DEL_MESSAGE} | ||
| _grl().call_exception_handler(context) | ||
| except RuntimeError: | ||
| pass | ||
| self.connection._close() | ||
| # try: | ||
| # if _sniff() == "asyncio": | ||
| # # trio trades global exception handling for local task groups | ||
| # context = {"client": self, "message": self._DEL_MESSAGE} | ||
| # _grl().call_exception_handler(context) | ||
| # except RuntimeError: | ||
| # pass | ||
|
|
||
| # self.connection._close() |
| self._close() | ||
| # self._close() |
| def _close(self): | ||
| """ | ||
| Internal method to silently close the connection without waiting | ||
| """ | ||
| if self._writer: | ||
| self._writer.close() | ||
| self._writer = self._reader = None | ||
| # def _close(self): | ||
| # """ | ||
| # Internal method to silently close the connection without waiting | ||
| # """ | ||
| # if self._writer: | ||
| # self._writer.close() | ||
| # self._writer = self._reader = None |
|
yes, its a different framework based on structured concurrency principles - so basically no free-floating tasks + strong guarantees about cancellations and execution scopes. the pycon talk by the author is pretty informative, if you're curious for more anyio is a bridge framework that implements trio principles in an agnostic way, so if im writing something using trio for structural sanity, i'd be able to use this py client (which is indeed the reason for the pr) im happy to help with static typing as well, if the problem is illustrated somewhere (or could be) |
there has been discussions in many places there are also general attempts to improve the typing situation of valkey-py, but i think the async parts are a different kind of problem, and need their own attention |
| default=[], | ||
| action="extend", |
There was a problem hiding this comment.
anyio's docs suggest (by example) parametrizing the tests by framework, but im not opposed to making this a single option per run if we want to keep it like that
on the invoke side i think it'd still make sense to specify several, but it'd just run the suite N times and dump to separate junit xmls instead of collecting all ~6.5k tests in one file
| for _ in range(11) | ||
| ) | ||
| ) | ||
| with pytest.raises(Exception): |
There was a problem hiding this comment.
note to self: exception group, same as above
|
im closing this PR in favor of this one in valkey-glide, since it sounds like the latter library is really the future for this project |
|
This project is still being maintained. Admittedly, I don't have a lot of time lately to keep up with the tasks, but I still try to keep it afloat. Please let me know if you reconsider adding support to trio to valkey-py as well. |
|
Understood! It's a bandwidth problem on my end rn, so if space opens up in the future I'd be happy to revisit. |
Pull Request check-list
Description of change
This PR adds Trio support to the async Valkey client through AnyIO. It's intentionally not a full refactor, just as close to a line-for-line port as possible (given small asyncio/AnyIO behavioral differences) to keep parity with the existing API.
I also updated the test suite to be anyio-based, as to test everything against whatever async runtime AnyIO supports.