Should we require 3.10 here then?

(My preference is to either support 3.9 or not, but you could convince me that keeping it a gray area like you usually do is a good idea.)

I have no problem dropping 3.9. I didn't want to remove it in this PR though, because I assume we are going to backport this PR to 9.2, 9.1 and 8.19, which do need the 3.14 support, whereas dropping 3.9 only applies to the upcoming 9.2, since I suppose we don't want to also drop it in 9.1 and 8.19 patch releases.

Also what you call the "gray area" to me means being nice to people by allowing the "requires-python" setting to lag a few releases. To me dropping support of a Python version and preventing people from installing on that version are different things.

So I'm 100% in agreement to drop 3.9. But I don't think it is necessary to bump this setting (which imho should still be 3.8), and I also don't feel necessary to run pyupgrade.

To me dropping support of a Python version and preventing people from installing on that version are different things.

I don't get this part. All popular Python libraries I know (Django, Flask, FastAPI, urllib3, all scientific libraries that endorse SPEC-0, etc.) don't do this. They either support or don't support a given Python version. When they don't support it, they use requires-python to clearly signal it. Well, even microdot, which currently supports Python 3.8+ and still tests it in CI.

Yes, for all my open source projects I'm at 3.8 right now. At some point I pyupgraded my code to 3.8, so I marked it as invalid for older releases, because it would obviously not work on them. This was not a decision related to what versions I support, but about what the version my Python code is at. Before settling on 3.8 I used 3.6 as baseline for my projects. All I'm planning to do now is to add 3.14 and drop 3.8 from the CI.

I do not feel it makes sense to prevent people from installing on 3.9, which went out of maintenance just days ago. I could be convinced to do this for the upcoming 9.2, but for patch releases on the older 9s and 8.19 it would be weird to do it.

I'm happy to keep Python 3.9 support for Elasticsearch 8.19 and older 9s. However, I suggest dropping Python 3.9 on elasticsearch-py 8.19 in one year, when Python 3.15 gets released. (We kept Python 2.7 forever on elasticsearch-py 7.17, and this was painful, especially as Github Actions and libraries we depend on stopped working and we no longer had CI.)

Feel free to decide about elasticsearch-py 9.2. But if we drop 3.9 in CI, I'll be very tempted to start using pattern matching, parenthesized context managers, and X|Y types. Without necessarily realizing it.

Okay, so this is what I propose:

• This PR will add 3.14 and will not remove 3.9. We'll back port it to 9.2, 9.1 and 8.19. We'll then release patches for 9.1 and 8.19 with 3.14 support.
• We'll add a separate PR that drops 3.9 for the upcoming 9.2 only. I feel a lot less strongly about keeping python-requires at 3.9 on a release that does not exist yet, so for this one release I'm fine bumping it to 3.10. I wouldn't pyupgrade the code immediately because I expect we will continue to back port things from time to time. Once the back port efforts slow down, we can run pyupgrade as well.

Thanks! LGTM.