Not a bad suggestion Michael, although it's a bit out of scope for my immediate concern. To your point, though, not only would the analysis you reference be useful for the Python driver but it's prolly a good thing to establish baseline performance numbers for _all_ the drivers. That way we could monitor performance changes over time in order to detect regressions for common workloads. We don't really do anything like that now; the closest we'd come would be the duration testing that's done every time we upgrade Netty on the Java driver. That process is undertaken specifically because we've seen regressions there in the past... so it's not a 1:1 mapping (since we aren't really using it to establish any kind of common baseline).
As to the point about starting the process of removing event loops... based on the replies seen so far I'm going to assume we're at a consensus here that this is a Good Thing :tm:. Specifically that we're okay with the following: * gevent, eventlet and Twisted reactors will be marked as deprecated with the next release (3.30.0, the first ASF-branded Python driver release). All reactors (including these three) will continue to be supported at this point. * These three reactors will be removed from the code base in the following release (tentatively 3.31.0). * The asyncore (for Python versions < 3.12), asyncio and libev reactors will remain in the code base and will not change status Unless somebody logs an objection that's what I'm going with. Thanks all! - Bret - On Wed, Feb 4, 2026 at 9:02 AM Michael Shuler <[email protected]> wrote: > 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 - > > > >
