Update supported Python versions

[noirbizarre]

Would you accept a pull-requests dropping support for unsupported Python version (2.7, 3.4, 3.5 and 3.6 from setup.cfg classifiers but depending on the places, GitHub actions workflows, tox, tested Pythons varies) and adding/exposing support for missing sported Pythons (3.11 and potentially 3.12). (see https://devguide.python.org/versions/ for current versions state)

This would be consistent with requests supported versions and would allow dropping the six dependency.

Plus, it would restore compatibility with latest tox and virtualenv given venv is now having some from __future__ import annotations which is not compatible anymore with Python < 3.7.

If you agree, I would gladly submit this pull-request.

[jamielennox]

At some point i recognize the need to drop 2.7, i was just expecting to do it when i needed a 2.0 release cycle and it hasn't come yet. Is there best practice on the semver requirements for dropping this support in python? As you say requests has done it.

So far it's just seemed unnecessary to me as keeping the support was easy to do. If there are actual problems starting to come up because of these dependencies then i guess that's a different story.

[noirbizarre]

I don't know if there is a proper official semver way to do so but from what I've seen, a common way is:

• mark as deprecated what you want to remove
• either you have a deprecation policy and you follow it (something like "deprecated parts will be removed on the next major")
• either you advertise the removal directly in the deprecation (raising a DeprecationWarning with a message like "this will be removed in the next major release (X.0)), in the readme and the changelog
• on the next major (more exactly the release targetted and advertised for removal), you can drop deprecated parts, refactor and cleanup

In the case of Python 2.7, or any part which already reached end of life, I see that most project don't go through a deprecation cycle given and drop support ASAP when it has been decided (given they were supporting something that is not supported by the editor/author itself). Most of the time, I see an intermediate solution were a last release in X.9 is published with the latest changes just before removal in (X+1).0. They can be released at the same time with the proper markers in setup.py, setup.cfg or pyproject.toml as unsupported Python version will properly fetch the latest X.9 supporting their version.

In the case of request-mock, I would do:

• flag all deprecations
• release a 1.11 (or any version between ]1.10,2.0[ according to your semver usage) advertising those deprecation and saying this will be the last release supporting those
• drop all deprecations
• release 2.0 (ideally with every refactoring and breaking change you want to bring in)

But this is my opinion and perception on this topic for what it's worth. I think the only downside for the moment is the inability to use 3.7+ only syntaxes and backported typing, so not that much a problem, just comfort and syntactic sugar for developpers.

[jamielennox]

See #248. Any advice welcome.

Whilst it's not my favourite thing, no library i'm aware of has bumped a major version for python3. Realistically this is a testing library so it's not going to be a big deal. Let's just do it.