bump minimum supported python version to 3.11 (released 2021)

[austinorr]

We currently support a lot of very old versions of python, especially related to our primary dependencies.
https://scientific-python.org/specs/spec-0000/

python 3.11 is not longer supported by python, but it's still supported by our major dependencies:
numba minimum python version is 3.10, 3.11 preferred
numpy minimum python version is 3.11

dropping support for python <3.10 will let us plan for the future, and start take advantage of tests that run with the 'jit' compiler in 3.14. This will also help us transition to pandas 3.x and numpy 2.x (we currently pin to numpy < 2 but v1 is no longer supported).

@rburghol @PaulDudaRESPEC @aufdenkampe @timcera Any objection to working toward modernizing? Keep in mind that old pypi versions will still work on old pythons.

[austinorr]

I tested numpy v2+ locally and it works fine, i don't think we need to pin it to <2.0 anymore now that numba has caught up.

I'll rebase this branch after @PaulDudaRESPEC merges #218 and the tests should then all pass -- they're failing on pandas 3.0.

edit: realized i should just let #218 include the dependency change for numpy too. That way tests can run and see if it works. I reverted this branch to be solely about python support.

[rburghol]

Personally I think we should allow the numpy 2+ and continue to allow for python < 3.12 -- does the earlier python support cost us anything other than some testing threads on github?

[austinorr]

The suggestion is to pin the project to >=3.11 not 3.12, and to stop testing on super old versions of Python.
Yes it does cost us a good deal of debugging, since we will have to begin pinning specific versions of numpy, pandas, and numba, depending on the Python version.

[rburghol]

It only causes debugging time in theory in some future and in reality the fact that we had 3.9&3.10 in the mix here allowed us to find the issues with pandas 3.0.0 because 3.9/10 installs only had <3.0.0 -- it literally was the path forward to debugging it.

[austinorr]

It only causes debugging time in theory in some future and in reality the fact that we had 3.9&3.10 in the mix here allowed us to find the issues with pandas 3.0.0 because 3.9/10 installs only had <3.0.0 -- it literally was the path forward to debugging it.

I think you're underestimating yourself. I'm sure you would have been able to determine that the issue was caused by a pandas release even without running tests on 3.9. Especially since we have tests on 3.11 with a variety of pandas versions (some worked some did not) and since tests run earlier in the week with the same code passed just fine. This happens all the time with dependencies releasing major versions.

I also believe that the debugging effort is not just a theory (see #220), and I'd like to invite others into this conversation about how to proceed given the following:

• tests fail on 3.9 without special pinning of numpy, pandas, and tables. Do we care? Our main dependencies do not care about 3.9 anymore, so for me this is a "won't fix" for our team since the first thing i'd to if a user came to me with this failure would be to say "does it run on 3.11 or 3.12?"
• tests fail with unpinned numpy when we run with pandas pinned to v1x. This is because pandas v1 doesn't cap numpy at <2. To support numpy v2 we'd have to catch this case in our project toml, or support only versions of pandas >2.0. I'd suggest the latter, since it's been over four years since pandas v2 was released and users have had plenty of time to move on from v1. I'd like to hear more from others with legitimate needs to stay on pandas v1.
• tests fail on 3.14 because pytables doesn't build wheels for 3.14 yet, though they're tracking it and likely getting close Python 3.14: Installation from source suddenly stopped working PyTables/PyTables#1262 . if we want to test on 3.14 we could do it by pinning pytables to <=3.10.1 and building it from source, but i'd say we should just wait until they publish wheels for 3.14 on pypi.

Additionally, the project would likely continue to work fine on 3.9&3.10 for quite some time, we just wouldn't bother our developer community with issues about those versions any more.

[rburghol]

Any objection to working toward modernizing?
Firstly, I have zero objection to modernizing, but this isn't the way it should go IMO. Moving towards code that is compatible with updates to numpy or numba are great, but this PR doesn't add any code, it just throws up a barrier. I think this should be an issue, not a PR at this point in time, related to moving forward to numpy 2.

I think you're underestimating yourself. I'm sure you would have been able to determine that the issue was caused ...
@austinorr - you are posing a hypothetical that I would have figured out the issue without the 3.9, and I'm relating my actual experience in this case -- I value my experience over hypotheticals.

Additionally, the project would likely continue to work fine on 3.9&3.10 for quite some time, we just wouldn't bother our developer community with issues about those versions any more.

I have two responses to this concept:

1. We don't have any version issues being introduced at this time that is bothering our developer community to my knowledge. When we start to have them, then it can be an appropriate time to make that decision.
2. I just realized that I have a compute node that is at this time limited to python 3.9, and since I'd rather not take it out of my arsenal (it is actually my fastest node, so, it's valuable), and I don't currently have the time to allocate towards it's upgrade (that is happening summer/fall 2026), I'd argue that for me as one of the developers, this change will cost me time, not save me time.

Finally I think the goals of moving towards code that is compatible with updates to numpy or numba are great, and I think that in the interest of everyone's time it is best to organically move this direction rather than cutting off working versions.