drop Python 3.6 support

[jonas-eschle]

End of live is in December, so we can drop it (it's causing issues in #63 as dependencies dropped 3.6 already) @redeboer is that fine? I assume that tensorwaves will also soon drop it?

[codecov-commenter]

Codecov Report

Merging #69 (64f28fd) into master (5e5ad5b) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #69   +/-   ##
=======================================
  Coverage   91.01%   91.01%           
=======================================
  Files           5        5           
  Lines         345      345           
  Branches       62       62           
=======================================
  Hits          314      314           
  Misses         20       20           
  Partials       11       11           

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 5e5ad5b...64f28fd. Read the comment docs.

[redeboer]

I also find it troublesome to keep supporting Python 3.6 code and increasingly run into dependency issues. However, two clusters on which we work (with venv) still have Python 3.6 and I wouldn't be surprised if other servers used by HEP communities also stick with this for some time to come. How is that in CERN collaborations?

[jonas-eschle]

I agree, this is somewhat similar. Scikit-HEP has a good statement on it, most notably that some are dropping it already and more to follow.

I would suggest to just go ahead with it and drop then. It still can be run on Python 3.6, but it won't receive any updates.

I think the burden of this legacy to keep the versions in is just too large in the end and rather hampers the actual developement.

In case there are crucial bugs, one could still think of backporting them oc if really needed.

[redeboer]

Just discussed this a bit with @wgradl, who had similar thoughts on Python 3.6 in RHEL8 and streams as referred to in the Scikit-HEP statement. We'll further discuss this in the group tomorrow, but it seems like it's fine to move on to 3.7+.

[eduardo-rodrigues]

I also find it troublesome to keep supporting Python 3.6 code and increasingly run into dependency issues. However, two clusters on which we work (with venv) still have Python 3.6 and I wouldn't be surprised if other servers used by HEP communities also stick with this for some time to come. How is that in CERN collaborations?

Speaking for LHCb we're focusing on Python 3.9 for now for next year's stacks :-). At this point, when forgetting about Python 2, there isn't indeed no reason not to go with a very recent version, and 3.8 is about the minimum anyway.

[jonas-eschle]

Great, LGTM!