Use of "less-than next-major-version" (e.g., `<4`) in `python_requires`

[Freso]

The documentation for the python_requires argument of setup.py gives some examples of various valid statements/strings/values for this argument. One of these is python_requires='>=2.6, !=3.0.*, !=3.1.*, !=3.2.*, <4', while the other relevant example (the >=3 one) does not include the <4. This has led to some doubts for whether to include the <4 when specifying version ranges.

sampleproject’s sample of python_requires includes <4, but there was no discussion about this (AFAICT) in the PR that added it other than referencing the above documentation.

I asked on Stack Overflow as well (which is how I was redirected here), and it seems so far the "consensus" among answerers is to not use it, even if it's actually used in official Python documentation. Should the documentation be updated, or at the Stack Overflow answerers wrong here?

When and in which case should python_requires include <4 (or less-than-next-major version in general)?

[dmtucker]

IMO, you should definitely have it... Major version bumps are for backwards-incompatible changes, which means there is no guarantee (or even expectation) that your package will work with it. It might, but if we think about the 2->3 transition, that seems unlikely to me. Even claiming support for minor version bumps can be risky (e.g. 3.7 made async a keyword which broke any code that had a variable named async).

Something I feel is pretty underused is the compatible release operator ~=. It can't be used in some cases, namely projects that support 2 and 3 (e.g. sampleproject), but it implies an appropriate upper bound by definition. I use it as much as possible.

[merwok]

I think dmtucker’s answer is for the general case, but does not necessarily apply to the Python version specifically.

After all the hard feelings and bad press of the 10-year long Python 3 transition, the BDFL (and I think the core team agrees) declared that there will not be another break-the-world major version update (major = X in X.Y.Z).

At one point it was thought that 3.9 would be followed by 4.0 just to keep one digit per component, but tools have had to be fixed when 2.7.10 came out, so that doesn’t have as much weight now.

Projects like linux kernel or Mercurial have moved from endless 1.x or 2.x lines to updating the major component without it meaning guaranteed breakage, not to mention the recent trend (started by chrome?) to avoid the slow-moving X part and just go to version YY.ZZ with abandon, or use year-month as components.

Before Python 3 existed, devs referred to Python 3000 (as a riff on Microsoft 2000 IIRC) for «things that would be really nice to change but can’t be done without massive breakage». This became Python 3 :) Now sometimes devs talk about removing long-deprecated functions, cleaning up or fully reworking the C API, changing drastically the internals of CPython (GIL! register-based VM!), and say things like «can’t be done before Python 4» or «Python 4000» as an analogy to what was Python 3000 before it was real.

So these two things are in conflit at the moment: an intent to never reproduce the massive compat break of Python 3, and a nickname for a future version that breaks some things to allow new things.