🌇 Sunset of Python3.6

[tkoyama010]

Overview

🌇 Python3.6 security support Ends in 2 months and 2 weeks (23 Dec 2021). Please merge this PR after the support ends.

Details

• https://endoflife.date/python
• See 🌇 Sunset of Python3.5 #905

[codecov]

Codecov Report

Merging #1716 (cbc34c3) into main (1c4855c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1716   +/-   ##
=======================================
  Coverage   93.31%   93.31%           
=======================================
  Files          75       75           
  Lines       15616    15616           
=======================================
  Hits        14572    14572           
  Misses       1044     1044           

[akaszynski]

I think we should wait a bit longer to merge this. While I'm a huge fan of dropping support for older versions of Python, if people are still using it we should still maintain a modicum of support for at least the next few months.

It appears, looking at numpy PyPI download stats, that there's still significant usage of Python 3.6, around the order of 18%. What we should aim for is a simple validation that the package works under 3.6 and that we don't add any non-backwards compatible features, at least until Python 3.10 is supported by VTK on PyPI.

[banesullivan]

+1 for waiting a bit longer

However, I'm wondering if those download stats should be taken with a grain of salt... I suspect most of those downloads are from CIs and most of the 3.6 downloads are just for testing. I'd be curious to see how those stats change in the next few months

Overall, I think we should wait until it becomes a burden before dropping support

[banesullivan]

FWIW, conda-forge dropped 3.6 a while ago so this is only relevant to PyPI

[adeak]

Based on a glance of the release notes the large changes in the subsequent two versions were

• 3.7:
  • Addition of stdlib dataclasses: I'm quite surprised that we're using these. We can just remove the line with the python 3.6 constraint in setup.py corresponding to the PyPI package when we drop 3.6 support.
  • Dicts preserving insertion order are now a language guarantee: it's still not a great idea to rely on this so I hope we don't plan to.
  • Postponed evaluation of annotations: this might actually be relevant in some places, but not very likely. It's probably not a huge deal to have string-valued type annotations (a'la PEP 484) in the few places where this is relevant, until 3.6 support is dropped.
• 3.8:
  • assignment expressions a.k.a the walrus operator: please, no, no no no no
  • positional-only parameters: I guess we could use these for the saucier __init__ methods like that of PolyData. Not critical.

Overall probably nothing we can't live without. The substantial improvement was the addition of f-strings in 3.6. But we already have that.

[MatthewFlamm]

I'm +1 on dropping support now, but I can see the other points too.

• Addition of stdlib dataclasses: I'm quite surprised that we're using these.

This was for the native pvd reader that was added. Otherwise, the implementation is much lengthier.

[adeak]

Otherwise, the implementation is much lengthier.

Oh, I wasn't complaining :) I just haven't yet run into a good use case for dataclasses, and I wouldn't have guessed that we have one in PyVista. Especially now that it's stdlib there's no reason not to use it if it makes life easier.

[akaszynski]

assignment expressions a.k.a the walrus operator: please, no, no no no no

Agreed. I can see some edge cases where this is useful, but I don't encourage its use.

[adeak]

assignment expressions a.k.a the walrus operator: please, no, no no no no

Agreed. I can see some edge cases where this is useful, but I don't encourage its use.

I can pretty much only accept their use in the opening line of a loop or conditional clause, i.e. something like

while line:=f.readline():
    # do something until EOF

Anything else is instant spaghetti code.

[banesullivan]

We should look at #2251 and makes sure everything 3.6-related is handled

[adeak]

One more reason why this would be nice to have: in #2175 a monstrous type alias could be replaced by just the name of the alias in the built docs if we can use the annotations future import.

[tkoyama010]

One more reason why this would be nice to have: in #2175 a monstrous type alias could be replaced by just the name of the alias in the built docs if we can use the annotations future import.

@adeak I don't know much about this. Can you please explain with an example?

[adeak]

One more reason why this would be nice to have: in #2175 a monstrous type alias could be replaced by just the name of the alias in the built docs if we can use the annotations future import.

@adeak I don't know much about this. Can you please explain with an example?

Sure thing! In the PR @dcbr introduced a type alias color_like which looks like this:

Normally if we had a color_like type annotation in a signature, it would expand to that monster of a type Union definition. Sphinx can instead substitute the name of the alias:

(note the Optional[color_like] at the start of the signature). But for this to work, apparently one has to opt-in to postponed evaluation of annotations via

from __future__ import annotations

a.k.a. PEP 563. And this feature is only available since Python 3.7, see e.g. the table at the bottom of the __future__ module docs.

[tkoyama010]

Got it. Sounds nice.

[adeak]

There seem to be a few things missing spotted by @larsoner in https://github.com/pyvista/pyvista/pull/2251/files, we should adopt their changes here.

[larsoner]

Looks like a few simplifications in setup.py are missing

https://github.com/pyvista/pyvista/pull/2251/files#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7

And some bumps in doc/extras/building_vtk.rst

https://github.com/pyvista/pyvista/pull/2251/files#diff-448e1594a0f3a728f0be7d0f182fd599376feb27f5bfd898449de780f2a41281

[larsoner]

Pushed a commit for the missing doc changes, plus a comment about deps being kept up to date by dependabot

[akaszynski]

Thanks @larsoner. Ended up committing at the exact same time you were.

Recommending that we merge this.

[larsoner]

Agreed!

[tkoyama010]

LGTM for additional changes. Thank you for making up the shortfall.

[larsoner]

All green, feel free to merge!