Drop support for Python 3.7

[cdce8p]

Description

Similar to pylint-dev/pylint#8609
EOL for Python 3.7 is 2023-06-27.

2.16.0 already includes a lot of (unintentional) breaking changes. We might as well include this one too.
Maybe even do 3.0.0 instead?

[codecov]

Codecov Report

Merging #2137 (f93c721) into main (f4a1168) will decrease coverage by 0.59%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2137      +/-   ##
==========================================
- Coverage   92.74%   92.16%   -0.59%     
==========================================
  Files          94       94              
  Lines       11001    10908      -93     
==========================================
- Hits        10203    10053     -150     
- Misses        798      855      +57     

Flag	Coverage Δ
linux	91.92% <100.00%> (-0.55%)	⬇️
pypy	87.22% <100.00%> (-0.64%)	⬇️
windows	91.75% <100.00%> (-0.55%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
astroid/__init__.py	100.00% <100.00%> (ø)
astroid/_ast.py	100.00% <100.00%> (+1.75%)	⬆️
astroid/bases.py	88.10% <100.00%> (-0.40%)	⬇️
astroid/brain/brain_dataclasses.py	94.21% <100.00%> (-0.08%)	⬇️
astroid/brain/brain_namedtuple_enum.py	92.90% <100.00%> (-0.08%)	⬇️
astroid/brain/brain_typing.py	86.11% <100.00%> (-0.29%)	⬇️
astroid/decorators.py	79.82% <100.00%> (-3.66%)	⬇️
astroid/interpreter/_import/spec.py	97.40% <100.00%> (-0.04%)	⬇️
astroid/interpreter/objectmodel.py	93.22% <100.00%> (-0.06%)	⬇️
astroid/modutils.py	85.91% <100.00%> (-1.41%)	⬇️
... and 8 more

... and 3 files with indirect coverage changes

[DanielNoord]

I'd be in favour of 3.0 and dropping 3.7. However, that would also mean that pylint 3.x would be 3.8+. I'll leave that decision to @Pierre-Sassoulas but I am in favour!

[Pierre-Sassoulas]

I wanted to support 3.7 until the end, but on the other hand releasing astroid/pylint 3.0 and then immediately removing support is not ideal either (the last version could be half broken). flake8 dropped 3.7 months ago, but ruff is still supporting it. Would dropping python 3.7 right now would make our life that much easier ?

[DanielNoord]

Would dropping python 3.7 right now would make our life that much easier ?

It removes a dependency and a lot of if statements.

We can also require end_lineno to be int for a lot more nodes, which feels like a good thing considering all the breaking changes to constructors. I'd say it is a definite improvement.

[Pierre-Sassoulas]

Releasing astroid 3.0 make sense too. The lambda/function def change is impactful and does break compatibility with old version of pylint. I have no problem in doing a "early 2000 firefox" and release a lot of major each time we want to break things.

[cdce8p]

Then let's go ahead with this one then?

I have no problem in doing a "early 2000 firefox" and release a lot of major each time we want to break things.

I think we should still try to bundle breaking changes at least as far as we can. To make it easier for us though, we could release alpha / beta versions for each new "area" of breaking changes. Those could then be pinned in pylint 3.0 to make adopting them easier. That way we wouldn't have to resolve all issues at once.

[Pierre-Sassoulas]

So the plan is to:

• drop python 3.7 in astroid
• Move all the issues from astroid 2.16.0 in astroid 3.0,
• Release astroid 3.0.0a0
• drop python 3.7 in pylint main branch
• Release astroid 3.0.0 once it works in pylint and we're sure of the breaking changes we did
• Release pylint 3.0.0b1

Right ?

[DanielNoord]

Agree with both of you. The earlier we release an alpha we can spot mistakes I made with the current breaking changes. It is hard to know what is wrong or good with the minimal security of the astroid test suite currrently.

Release plan also sounds good!

[cdce8p]

So the plan is to:

• drop python 3.7 in astroid
• Move all the issues from astroid 2.16.0 in astroid 3.0,
• Release astroid 3.0.0a0
• drop python 3.7 in pylint main branch
• Release astroid 3.0.0 once it works in pylint and we're sure of the breaking changes we did
• Release pylint 3.0.0b1

I would modify that a bit:

• Drop Python 3.7 in astroid + pylint (can be done independently on one another - i.e. we don't need a new astroid release to merge Drop support for Python 3.7 pylint#8609)
• Move all the issues from astroid 2.16.0 in astroid 3.0
• Update changelog
• Release astroid 3.0.0a0
• Do additional breaking changes, cleanup, and fix bugs, e.g. remove cachedproperty, change TryExcept and TryFinally to just Try Add Try node #1867, changes to the Import nodes Add an alias ImportFrom.module and fix other inconsistencies with the ast module #1338, ...
• After each major change release new alpha for astroid
• For pylint 3.0 beta: Update pinned astroid version to use latest alpha release
• Once everything works and most/all of the changes are done -> release astroid 3.0
• ...
• While doing this: Continue to release new pylint 3.0 alpha or beta releases so we can gather feedback

[DanielNoord]

I would only argue that this should be at the top of our changelog for the 3.x version. Rest LGTM! Thanks @cdce8p

Done