Consider making asyncio reactor the default

Somewhat blocked without asyncio support since linking with libev appears unreliable on macOS, and we’ve been able to move all of our other packages to 3.12. Any help is greatly appreciated. What is the likelihood asyncio support can make it in with support for 3.13 generally (https://datastax-oss.atlassian.net/jira/software/c/projects/PYTHON/issues/PYTHON-1413)?

Yesterday I reviewed the PR trying to help. I agree with the changes and observe that the changes are not that wild. Maybe they could land in some earlier version of the official driver, i.e. 3.29.2?

Agreed . Following our policy we’ll support whatever runtimes are not EOL at the time of release so as long as we get 3.30.0 out the door before the end of October (which very much is my goal) then we’ll include 3.8 in there. If we do get delayed then we have a different problem as 3.13 should then be in a general release at that point… meaning we’d have to support a new version.

My suspicion is that 3.30.0 will be the last release that officially supports 3.8 and doesn’t support 3.13… but we’ll see how work goes on the release.

Python 3.8 is EOL RSN, in 5 months, Oct 31st 2024. So depending upon driver release plans, it might make sense to plan a 3.30 which uses asyncio and supports Python >= 3.9.

We’re only supporting Python 3.8 up to 3.12 for current releases and asyncio was reasonably stable by Python 3.8 so my inclination is to just make it the default once we have it in a good place. That approach simplifies support/debug operations; under that config we don’t have to ask customers which Python version they’re running in order to know which reactor they’re making use of.

If we really can’t get asyncio to a good place in a reasonable amount of time we might constrain it to 3.12 (or 3.10 as you mention) but I guess I’d really just prefer to keep it simple and make it the all-around default.