bpo-42843: Doc: Bump Sphinx min-version (needed as we use :no-trim-doctest-flags:).

[JulienPalard]

Bump min sphinx version (thanks @asottile noticing in #23620 (comment))

This needs no backport, but please don't merge until there's a concensus on b.p.o.

https://bugs.python.org/issue42843

[asottile]

CC @mcepl @pablogsal re: b63a620

[mcepl]

What can I say? It is a bad idea: why do we want to eliminate more platforms from being able to build Python? Yes, of course, we Linux enterprise distributors will again patch that nonsense away, but it is just making our life more difficult.

Also, this is one more proof (as if we need more of them) that doctests are bad idea. They could be useful for some very limited areas of testing, but they are so limited that their authors are now trying again to sneak in yeat another one-purpose programming language in commentaries to overcome their deficiencies.

[pablogsal]

What can I say? It is a bad idea: why do we want to eliminate more platforms from being able to build Python? Yes, of course, we Linux enterprise distributors will again patch that nonsense away, but it is just making our life more difficult.

Also, this is one more proof (as if we need more of them) that doctests are bad idea. They could be useful for some very limited areas of testing, but they are so limited that their authors are now trying again to sneak in yeat another one-purpose programming language in commentaries to overcome their deficiencies.

Thanks a lot, @mcepl for expressing your concerns regarding this change. I assure you that no one is trying to make life more difficult for anyone so please, avoid referring to patches as "nonsense" or mentioning that "authors are now trying again to sneak in yeat another one-purpose programming language in commentaries to overcome their deficiencies" although I agree with some of your concerns, there may be people that disagree with those statements and there is no need to express them in an aggressive way. Thanks for your understanding.

[mcepl]

Thanks a lot, @mcepl for expressing your concerns regarding this change. I assure you that no one is trying to make life more difficult for anyone so please, avoid referring to patches as "nonsense" or mentioning that "authors are now trying again to sneak in yeat another one-purpose programming language in commentaries to overcome their deficiencies" although I agree with some of your concerns, there may be people that disagree with those statements and there is no need to express them in an aggressive way. Thanks for your understanding.

Thank you for being my PC police officer today, but I don't think your help is really needed here. Anybody who would at least try to understand what I was writing about, would understand that by “sneaking” I don’t mean anything morally wrong, but the tendency of all those ”simple solutions” to survive and try to claim to be simple, while they are forced by the evil world to be anything but that. So, we have originally simple JSON (”which shows whole XML world with its schemas, validators etc. how stupid they are, when the document transfer can be simple” and now we have schemas and validators for JSON as well), or yet-another-replacement-for-autotools-which-claims-to-be-simple (cmake, scons, ninja, meson, waf!) which turns later into horrible monster quite similar to autotools. It seems to me doctests are following exactly the very same trajectory, and sacrificing portability to older platforms for their sake seems to me like a quite bad deal.

[mcepl]

OK, after discussion with @vstinner … if we are talking only about Python 3.10+, then I am probably really silly. Sphinx 3.2 it is.

[JulienPalard]

Let's make it clear: this PR should not be backported, it's for Python 3.10 only.

[asottile]

alrighty, given that I'm going to stop distributing the docs with deadsnakes

the aggressive deprecation of ~6 month old sphinx versions makes it impossible to keep building cleanly even for the latest LTS release of ubuntu 20.04, I have no hope of docs building successfully on 18.04 or 16.04

[JulienPalard]

the aggressive deprecation

Please note this PR is marked as DO-NOT-MERGE, I'm trying to gather as much feedback as possible, I'm not sneaking this PR without conversation, and I'm open to hear that it's not possible.

While you're here I'd be happy to learn something: why relying on packaged Sphinx to build the doc, instead of a Sphinx in a venv like the Docs/Makefile does?

[asottile]

the aggressive deprecation

Please note this PR is marked as DO-NOT-MERGE, I'm trying to gather as much feedback as possible, I'm not sneaking this PR without conversation, and I'm open to hear that it's not possible.

While you're here I'd be happy to learn something: why relying on packaged Sphinx to build the doc, instead of a Sphinx in a venv like the Docs/Makefile does?

diverging from debian upstream creates more maintenance burden

[JulienPalard]

I'm opening #24282 to keep Sphinx 2 compat for a few more releases.