Consider removing upper bound constraint on python version

[yakMM]

Summary

The library have a upper bound constraint on the python version (currently 3.12).

I suggest dropping the upper bound constraint: python_requires=">=3.8.0" instead of python_requires=">=3.8.0,<3.12".

Why is this needed?

See this blog post for reference, especially the part about python versions

Basically I want to experiment with python 3.12 and hikari is the only library in my project with upper bound constraint, preventing my dependency solver to work properly.

Furthermore, hikari being capped is forcing any library or application depending on hikari to cap the python version as well.

Ideal implementation

N/A

Checklist

• I have searched the issue tracker and have made sure it's not a duplicate. If it is a follow up of another issue, I have specified it.

[davfsa]

Thank you for taking the time to create the issue, but I do not think this is likely to change for these reasons:

1. The main reason the top restriction exists is to ensure that the library works before opening it up to using newer python versions. This is done just like for dependencies, as we want to ensure that functionality still works and there are no issues.
2. 3.12 wont currently work with hikari due to its dependencies not supporting it, mainly aiohttp, yarl and multidict (see Add Python 3.12 support #1357). When those issues are fixed, the requirement will be bumped and a release will be made.

[yakMM]

Thank you for your response. To clarify, I'm not asking for hikari to support python 3.12 dev right now, but just to drop the upper bound.

None of aiohttp, yarl or multidict are using an upper bound limit on their require-python, despite effectively not supporting python 3.12, as you noted.

This is probably because using upper bounds on require-python was not really intended and is breaking badly dependency solvers (see this discussion).

I understand the argument of wanting to be clear about what python versions are supported, but I believe it is better to convey the information without using upper bound on python_requires (for example with the classifiers field, or in the docs). This will allow users to test newer versions for themselves and will make the library run as soon as possible on newer python version, without any work from maintainers (when no breaking change is present ofc).

In this instance, the install will still fail on python 3.12 obviously, but that will be the user responsibility as long as the version is not officially supported by you.

The third party libraries that you mentioned are a good example of the underlying problem with upper bounds actually: you are able to test python 3.12 on your CI exactly because they are not using upper bounds on python_requires! This should apply to hikari as well imo: someone wanting to test their app/library on python 3.12 should be able to do it without being restrained by the upper bound on hikari's python_requires, and would want their CI to fail the same way yours did (or succeed if there is no breakage).

Sorry for the long text, I'm waiting to hear what you think :)

[davfsa]

This is probably because using upper bounds on require-python was not really intended and is breaking badly dependency solvers (see this discussion).

This is not true, the example the discussion gives with Numba is due to pip not finding an available wheel candidate but them publishing the source code to compile as available for all python versions, would cause pip to download that and try to build it, which would fail in a crash because Numba didn't work in that version. This is what happens with aiohttp, yarl, etc, because they are compiled and need to provide wheels. If you try to install hikari with a development 3.12 installation, you will just get a error from pip saying no candidate was found for installation, which I think is fine.

Additionally, in the discussion it quotes the PEP:

This field specifies the Python version(s) that the distribution is guaranteed to be compatible with.

which is pretty much what we are providing here. A guarantee that the hikari version works on the specific python version. (This is also largely done to prevent "hikari doesn't work on this version, pls fix" when all they need to do is update nightmare)

---

someone wanting to test their app/library on python 3.12 should be able to do it without being restrained by the upper bound on hikari's python_requires

Hikari wont even run until it's properly updated for 3.12 (dependencies wise and some code), so what prevents you from setting up CI and seeing that it will in fact not work, keep that PR open until it's ready and then merge it once hikari supports 3.12? (Similar to our PR for 3.12, there is nothing we can do until the dependencies get fixed, which would need a version bump anyways)

Sorry also for the long text, lmk if I missed anything or have any other points you would like to raise :)

[davfsa]

Since no further comments have been made, I'll be closing this.

If you have any other questions, please comment here again or open a new issue!