Add flake8-typing-import to the pre-commit configuration

[Pierre-Sassoulas]

Type of Changes

	Type
✓	✨ New feature

Description

This permit to check that the typing is valid for all python version. Relates to #5068

It seems we have some trouble with python 3.6.0 right now:

pylint/testutils/output_line.py:71:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/testutils/output_line.py:85:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/testutils/output_line.py:91:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/testutils/output_line.py:99:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/pyreverse/printer.py:43:5: TYP005 NamedTuple does not support defaults in 3.6.0
pylint/pyreverse/printer.py:44:5: TYP005 NamedTuple does not support defaults in 3.6.0
pylint/pyreverse/printer.py:45:5: TYP005 NamedTuple does not support defaults in 3.6.0
pylint/pyreverse/printer.py:46:5: TYP005 NamedTuple does not support defaults in 3.6.0
pylint/checkers/similar.py:206:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/checkers/similar.py:211:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/checkers/similar.py:219:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/checkers/similar.py:222:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/checkers/refactoring/refactoring_checker.py:164:5: TYP005 NamedTuple does not support defaults in 3.6.0
pylint/checkers/refactoring/refactoring_checker.py:165:5: TYP005 NamedTuple does not support defaults in 3.6.0
pylint/checkers/refactoring/refactoring_checker.py:166:5: TYP005 NamedTuple does not support defaults in 3.6.0
pylint/checkers/refactoring/refactoring_checker.py:168:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/checkers/refactoring/refactoring_checker.py:171:5: TYP004 NamedTuple does not support methods in 3.6.0
pylint/checkers/refactoring/refactoring_checker.py:181:5: TYP004 NamedTuple does not support methods in 3.6.0

We can fix them in 2.11.0 or upgrade to 3.6.2 right now, what do you think @DanielNoord @cdce8p ?

[coveralls]

Pull Request Test Coverage Report for Build 1378234606

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 93.295%

---

Totals
Change from base Build 1377628875:	0.0%
Covered Lines:	13678
Relevant Lines:	14661

---

💛 - Coveralls

[DanielNoord]

If #5068 is scheduled for 2.12 I think should also be added to that milestone. Otherwise we're doing double work.

After that the dependency and python version should probably be updated to 3.6.2.

After that I don't see any problems with this.

[cdce8p]

It seems we have some trouble with python 3.6.0 right now: [...]
We can fix them in 2.11.0 or upgrade to 3.6.2 right now, what do you think?

I checked to see when these changes were introduced. In the end I'm still be bit surprised that we haven't gotten any bug reports for 3.6.0.

File	First version	Commit	Likely issue for pylint
pylint/testutils/output_line.py	2.9.0	304c87c	No, used just for tests
pylint/pyreverse/printer.py	2.10.0	7bb5043	No, just pyreverse
pylint/checkers/similar.py	2.10.0	1d1619e	Yes
pylint/checkers/refactoring/refactoring_checker.py	2.9.4	dd54e55	Yes

--
Usually I would have said that it would be better to fix the issues in 2.11 so we can ship one last fully supported version. However considering these date back to 2.9.4 and we haven't gotten any reports, combined with the nearing EOL for 3.6. It might be easier to just drop the support now. I.e. moving #5068 up to 2.11.2. Since it's technically already broken, bumping python_requires could be considered a bugfix.

[cdce8p]

Just though about one more thing: It might be the case that Python 3.6.0 still runs. Just the implementation for default values and methods might be broken internally. Can't confirm it though

[Pierre-Sassoulas]

Yes I also think, that the default value is probably not a crash, the method in a testutil class is probably only a problem when launching the test with 3.6.0 or 3.6.1. The only thing then could be the method in LineSetStartCouple but we never got any issue opened for it afaik ?

Best practice would be to fix it and release a last working version for 3.6.0 and 3.6.1 but I think there are very few users on those interpreter. If you're on the very first two versions of a dying python interpreter chances are you're also on a dying pylint.

So I agree with

moving #5068 up to 2.11.2. Since it's technically already broken, bumping python_requires could be considered a bugfix.

[DanielNoord]

Do we know if there are any current bugs specific to 3.6.0/3.6.1? If so, we might want to have a look if they are easily fixable and release one final minor version for them. Other than that I agree with what's been said here!

[cdce8p]

Do we know if there are any current bugs specific to 3.6.0/3.6.1? If so, we might want to have a look if they are easily fixable and release one final minor version for them. Other than that I agree with what's been said here!

No issue specific to 3.6.0, but we fixed at least some present for all Python versions. Thus a final release with 3.6.0 support might be best after all.

So my proposal would be:

• Fix issues planned for 2.11.2 and release it
• Shortly there after, finish + merge Require Python 3.6.2 #5068 and this one
• Release 2.12.0 (even without major new features)
• Any new bugfix will then be part of 2.12.1