Update Python version boundaries to include 3.12

[cdce8p]

Change python requirement from >=3.7, <3.12 to ^3.7. This will allow the library to be installed in Python 3.12 (and up) environments.

[cdce8p]

This currently block https://github.com/jpbede/pydiscovergy/issues/78 and first tests with Python 3.12.

Would be awesome if a new version could be released, after it has been merged.

[matt035343]

Hi, thanks for your contribution. Please add CI for Python 3.12 as well. Also, we will probably need some time to guarantee that our current code base does not break with 3.12 before merging this.

[george-zubrienko]

Hi, thanks for your contribution. Please add CI for Python 3.12 as well. Also, we will probably need some time to guarantee that our current code base does not break with 3.12 before merging this.

I second this, all hands for 3.12, but we can't allow installation on 3.12 without running units on it. Please update your PR:

• change version boundary to >=3.7, <3.13
• run poetry update so lockfile contains updated wheels etc and commit the updated poetry.lock
• Add 3.12 to the version matrix in pythonpackage.yaml line 22

[cdce8p]

I've added 3.11 and 3.12 to the CI config. However, I would strongly advice against pinning <3.13 for Python. It will limit what all downstream packages can use. There was a whole discussion about it on the Python forum (link below) but the jist of it is that the Python requirement should only be used to specify the minimum supported version. Even if a new Python release might break something.

A package doesn't guarantee support for it just by leaving the requirement open. That's what classifiers like Programming Language :: Python :: 3.10 are for.

https://discuss.python.org/t/requires-python-upper-limits/12663

[george-zubrienko]

Even if a new Python release might break something.

I tend to disagree with Python community on this one, because it leads to constant version pinning and usually this is not how dependency management is handled in language ecosystems with more mature package management. However, I'd say @lidatong should have a final say here :)

[cdce8p]

Even if a new Python release might break something.

I tend to disagree with Python community on this one, because it leads to constant version pinning and usually this is not how dependency management is handled in language ecosystems with more mature package management.

Not sure I follow. IMO version-pinning is useful for applications. They make sure to test their package with the pinned dependencies and can thus guarantee that everything is working. However for libraries adding an additional constraint means much more work for everything downstream.

In particular, the <3.12 constraint here, prevents us from updating https://github.com/jpbede/pydiscovergy, which in turn limits which versions we can test for https://github.com/home-assistant/core. That's especially an issue with poetry which enforces the Python constraint downstream as well. So from my perspective, it just means much more work when essentially the library worked with Python 3.12 to begin with.

That's why I recommend only adding a lower bound for Python.

[matt035343]

I fully agree with @george-zubrienko. Especially when you think about this library is so tightly coupled with Python's typing system which has frequent changes. Then bumping the Python upper version bound on-demand seems reasonable to me. My thought is that once the community is ready to upgrade, they will make an issue or PR (just like you), then we will have a look if the library is ready to have its Python bound bumped or if there are some issues to iron out first. For 3.12 specifically, there does not seem to be much surface area to cause bugs for us, but I do not know what the future Python minor versions will bring.

@lidatong's opinion would be appreciated here.

[george-zubrienko]

Just a side note, the thread in question is less about upper bounds themselves, but more about using Requires-Python for that matter. The topic starter also states that if you want to block support of a specific version at install time, you can do it similar to OS support locks:

Of course you can upper bound a wheel without Requires-Python, the same way you should upper bound the wheel with Requires-Python today, because Requires-Python is broken. You add a dependency on a package like "unsupported_python; python_version>=3.10". Then unsupported_python would be an SDist package that breaks with a error message. This is also how you would force Windows or some OS you don’t support to error out - why isn’t anyone asking for that? I would hope not supporting an OS is much more common than limiting Python! Also special architectures, etc. But Requires-Python is enticing people because it looks like it you should be able to set upper limits, but it causes problems.

I do agree with the sentiment that using Requires-Python for upper bounds is not an ideal solution, but I do not think that means upper bounds are absolute evil. In a world of Java, where any Java 10050 can run Java8 code, I agree there is no real value in scoping the lib to specific Java version range. But in a world of Python typing, which this lib heavily relies on, this unfortunately doesn't hold true, and we would rather take an issue for an upgrade to Py3.13 or later when it comes, instead of taking 20 issues for various bugs occuring when people try to use the lib with Py3.13 or later. IMO.