Remove upper bound checking on Python version

Issue Kind

Change in current behaviour

Description

Remove upper bound checking on the requires-python and python version specifier for a Poetry project. There is a lot of practical experience that shows upper bounds on Python versions can lead to difficult situations when managing Python dependencies. This thread has a good discussion about them:

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

One practical one that comes up is how Poetry's upper bounds on the Python version becomes "viral". If I depend on a package with an upper bound on the Python version, then I must also add that upper bound to my package or else Poetry won't resolve it (falling back potentially to an old version of the dependency otherwise). This then can trigger other packages using Poetry and so on.

Edit: The issue above can be solved in Poetry 2: https://python-poetry.org/docs/pyproject/#requires-python

uv has already removed requires-python upper bound checking:

• https://github.com/astral-sh/uv/pull/10964

Poetry took a small step toward this as well

• https://github.com/python-poetry/poetry/pull/9558

I'd propose that it would be a net benefit to follow uv's position here in Poetry as well.

Impact

Users relying on upper bounds of Python version could be impacted. Since Python 4.0 is no where in planning (may never happen) the old default Poetry packages that add this likely had little actual effect/meaning.

Start by tracing Poetry’s handling of the requires-python and python version specifiers during dependency resolution, then read the linked uv and Poetry pull requests for the intended behavior. Done means upper bounds are no longer enforced while the impact on users relying on them is covered by appropriate tests.