coredis vs redis.asyncio

[nrbnlulu]

hey, I am aware that lib is old enough to stand for its own, still it have only 97 start (not that it tells much) and I think it would be valuable to know how coredis compares to the "official" reids-py.
BTW, I am mostly attracted here due to type-hints

[alisaifee]

Sorry, I don't normally use discussions so I didn't see this question.
Specifically what are you looking for in terms of comparison that you don't see in the documentation?

There a small second on divergence from redis-py here but it's pretty brief.

[nrbnlulu]

np, thanks.. I mostly mean benchmarks and api\philosophy..

There a small second on divergence from redis-py here but it's pretty brief.

haven't seen that, thx.

[93578237]

What's the reason to deprecate and remove monitor? I find it pretty useful for testing

[93578237]

Somewhat related: some modules were deprecated and removed in coredis so for now redis-py is more "batteries-included"

[Graeme22]

Somewhat related: some modules were deprecated and removed in coredis so for now redis-py is more "batteries-included"

Except coredis also has commands that redis-py doesn't (caching in async clients for example) so it's not quite as simple as saying "X supports more commands" or "Y has more features"

[alisaifee]

@93578237 your thread / comments don't appear to be in the spirit of creating a constructive discussion.

I'll still answer your actual question though:

Monitor support was dropped because the implementation in 5.x (see ) and previous versions did not align with the direction the project is going.

One of the most important features of 6.x is to support anyio (and therefore trio) and to restructure the library internals to provide a much better experience to developers by providing structured concurrency. A strong secondary goal of 6.x is to rip off the weak pieces of duct tape that were holding together some of the legacy implementations and removing things that (I feel) are not internally consistent with the library or provide little value. MONITOR is one of those things. MONITOR uses a non standard way of returning data to the connection which is neither request->response nor push messages and therefore not consistent with RESP (see MONITOR return information) and therefore would require a workaround to be implemented in 6.x.

[93578237]

Yes, anyio support is a huge advantage over redis-py.

Thanks for clarifying why monitor was deleted. It would be good to have it still even as a snippet in docs

[alisaifee]

It would be good to have it still even as a snippet in docs

It's actually not possible in the way the the protocol is implemented at the moment. If there's a strong argument for implementing monitor (or if there are some other use cases for streaming non standard messages from the server) you can open an issue.

[alisaifee]

I don't think there's much more to discuss here, but feel free to re-open or create a new discussion.