Remove upper bound from Python version specifier

[sisp]

What is the problem that this PR addresses?
Capping the Python version (e.g. <4) is a bad practice.

• fix: Remove '<4' from python_requires in packaging guide pypa/packaging.python.org#850
• https://iscinumpy.dev/post/bound-version-constraints/#pinning-the-python-version-is-special
• https://discuss.python.org/t/requires-python-upper-limits/12663

How did you solve it?
I've removed the upper bound, i.e. I've replaced the version specifier ^ by >=.

Checklist

• I have read the Contributor's Guide.
• I will check that all automated PR checks pass before the PR gets reviewed.

[kiancross]

Thanks for the PR @sisp. I'll have a read of those articles/PRs this evening. What are the downsides to removing the maximum Python version?

[sisp]

@kiancross Poetry will throw an error during dependency resolution when any of the dependencies in the tree uses a maximum version. To fix that, the project itself needs to declare that maximum version, too. That's one of the reasons why this bad practice is spreading; a library author - when using Poetry - may be forced to add the upper bound because one of the dependencies has it.

[sisp]

Any update on this PR, @kiancross?

[kiancross]

Sorry @sisp, I haven't had time to properly understand why this might be necessary and I'm concerned that it might be a breaking change for some users.

@tmbo do you have any thoughts?

[sisp]

Check also isort, I raised an issue there about this topic a while ago and it was resolved with the recent v5.11.0 release.

[layday]

Sorry @sisp, I haven't had time to properly understand why this might be necessary and I'm concerned that it might be a breaking change for some users.

This will simply allow downstream Poetry and <insert dependency manager> users to lock their dependencies without having to set an upper bound for Python in their own project. Currently, projects which depend on questionary will need to declare that they do not support Python >= 4 because questionary doesn't either. Essentially, Poetry's practice of capping Python is changing the calculus for the eventual Python 3 -> 4 transition and some people are uncomfortable with that, as well as generally being opposed to upper-capping abstract dependencies.

[sisp]

Exactly.

[kiancross]

By removing the cap, are we stating we support Python >= 4, despite the fact we possibly do not? If it's a non-breaking change, then happy to merge.

[sisp]

Correct, and the consensus is that this is fine despite no guarantee at this point that questionnary will work without change with Python 4+. It isn't a breaking change because we'd be allowing more Python versions than right now.

[kiancross]

Ok. Just waiting for #270 to fix the current CI issues, then I will merge this after. Sorry for the delay, and thanks for your contribution :)

[BrianPugh]

I'll also be needing this :D. Thanks sisp!

[kiancross]

Once the minor merge conflict is resolved, I can merge. If you don't have time to fix, I can merge the branches later:)

[sisp]

@kiancross I've resolved the merge conflict.