Start requiring Python 3.6.2 or newer

[cdce8p]

I would like to propose to drop support for Python 3.6.0 and 3.6.1 a bit ahead of schedule. This would allow us to use some typing feature added in 3.6.1 and 3.6.2 while still maintaining general support for Python 3.6 until its end of support in December.

Python 3.6.1

• Default values for NamedTuples
• ChainMap, Counter, Deque, AsyncGenerator

Python 3.6.2

• NoReturn
• AsyncContextManager

--
At the moment, we already use Counter and NoReturn wrapped in if TypeChecking or if sys.version_info checks.
There are good usecases for default values in NamedTuples as well. Especially with the ongoing refactoring effort.

--
For reference: #4310

[cdce8p]

/CC: @Pierre-Sassoulas, @hippo91, @DanielNoord

[DanielNoord]

Is there any reliable way to get user statistics? I saw some discussion in the referenced issue and this would be helpful.

I am relatively new to the python (and pylint) community so my main question would be if there are any real obstacles which make it impossible for user to upgrade to 3.6.2 from 3.6.0. Considering the semversion, I don't suppose so but people with more experience might have more educated answers to this. If there are no real obstacles I'd we can go ahead.

[DudeNr33]

There are some situations where upgrading a Python version, even just a small step like this, is difficult.
For example if you work on an embedded device, or if you use it in commercial applications and would need to repeat an OSS clearing if you update the version.

Both points deal more with production code, but there can be instances where users want to use the exact same Python version in their test environment (this makes at least very good sense for dynamic tests).

But the real question is, if those corner cases should hinder us from dropping the support.
A) I don't think it will affect that much users
B) 3.6 reaches its EOL in just 3 months, so this does not really make a difference

[Pierre-Sassoulas]

I'm on mobile so I'll try to stay short.

I think black did it, so we can probably too. Also the pipystats link in the old issue is still valid and show a dramatic drop in 3.6 usage recentely (New Debian with 3.9 ?) which probably indicate that < 3.6.2 usage is even lower now.

[cdce8p]

The black PR with which they started requiring 3.6.2: psf/black#1668
From what I can tell their reasons have been similar to the once I mentioned in the beginning: Especially the support for NoReturn and default values for NamedTuples.

If we reach a conclusion, I would suggest to drop support in 2.12.

[cdce8p]

@pkolbus You originally fixed the issues with 3.6.0 and Counter + NoReturn in #4446. Would this change work for you?

[pkolbus]

@cdce8p, thanks for looping me in. Yes, with the update to python_requires, #5068 is workable; anyone using the old patch versions will just get the older pylint releases. (And our migration away from 3.6.0 is nearly complete, so we’ll hopefully be able to upgrade pylint and other packages soon).

[cdce8p]

@pkolbus Thanks for the feedback! Just out of curiosity: Are you still able to run pylint at the moment (on Python 3.6)? We discovered in #5070 that there might be some existing issues, in particular with NamedTuples.

[pkolbus]

@cdce8p I’m still pinning pylint to 2.7.x at the moment. Have deprioritized upgrading any packages for a few months now because these typing compatibility issues were just getting too widespread. (Pallets projects, and even pip).

[cdce8p]

@Pierre-Sassoulas and I had a small discussion about the next release. We have quite a few things planned which is way it doesn't necessarily feel right to release it as 2.11.2. Instead going for 2.12.0 directly might be the way to go.

Do we want to merge #5068 and #5070 then, or move them to 2.13?

--
#5094 (comment)