In addition to previously mentioned functional testing for allthethings,
I'd suggest performance being also very interesting to validate &
improve with base library/lang changes such as proposed. Python's been
less performant in general, if I recall, so it would be awesome to
verify correctness as well as scalable, robust, fast usefulness. Makes
me remember some fun with really large test clusters in all the clouds,
different clients and payloads - anyone doing these lately or regularly
with graphs for the win? Thanks so much!
Kind regards,
Michael
On 2/3/26 12:26 PM, Bret McGuire wrote:
Thanks Dinesh! Apologies, I should've been clearer. My proposal is
to deprecate (and then remove) eventlet, gevent and Twisted. That would
leave us with only the three most commonly-used event loops: asyncore,
asyncio and libev.
- Bret -
On Tue, Feb 3, 2026 at 1:23 PM Dinesh Joshi <[email protected]
<mailto:[email protected]>> wrote:
I'm in support of this proposal. However, even after eventlet
removal, leaves us with 5 eventloop libraries/frameworks? Is there a
reason to have 5. Is there value in keeping all 5 or look at
potential ways of deprecating and consolidating on 2-3?
On Tue, Feb 3, 2026 at 11:04 AM Bret McGuire <[email protected]
<mailto:[email protected]>> wrote:
Greetings all!
I've filed CASSPYTHON-9 <https://issues.apache.org/jira/
browse/CASSPYTHON-9> to document the details but since this
would be at least a semi-significant change for the driver I
thought it was worth at least bringing it to the list. The JIRA
ticket has the details but the short version is that asyncore,
asyncio and libev are the most commonly used event loops (based
on what we used to see from our customers). Furthermore I would
expect that most users will leverage asyncore or asyncio (once
we get it right) since those are included with Python itself.
Two other points are relevant here. First, keeping these
event loops does have a cost (albeit not a huge one) in that we
have to test driver code using these event loops and support
them as well. I'd like to minimize that cost for something that
doesn't get _that_ much use. Second, I'm not saying this code
should vanish from the earth. If someone feels strongly about
continuing to maintain these reactors they can move some or all
of them to an external library and maintain them going forward.
I'm simply arguing that the Python driver team needs to
consolidate its resources... and I'd rather focus on making
asyncore, asyncio and libev awesome.
Thanks all!
- Bret -
