Drop support for py2, py35 and py36

[xiki-tempula]

I was thinking of dropping support for py2, py35 and py36.

Python 2 reached the end of its life on January 1st, 2020.
Python 3.5 reached the end of its life on September 13th, 2020.

Python 3.6 will end in 7 months. However, as discussed in #125, I'm interested in using pandas.Dataframe.attrs which only becomes relatively bug-free from 1.2. pandas 1.2 would only support from py37.

[orbeckst]

Yes, I agree. (EDIT: on dropping 2.7 and 3.5)

Let's see if we should make a final release that supports legacy python.

[orbeckst]

For 0.4.0 we said it's the last one to be tested against 2.7 and 3.5.

We can't really drop 3.6, though. What are the bugs in attr in pre-1.2 pandas?

[xiki-tempula]

@orbeckst
So for pands > 1.2

>>> import pandas as pd
>>> d = {'col1': [1, 2], 'col2': [3, 4]}
>>> df = pd.DataFrame(data=d)
>>> df.attrs = {1:1}
>>> df.attrs
{1: 1}
>>> df['col1'].attrs
{1: 1}

for pandas >=1.0 and < 1.2

>>> import pandas as pd
>>> d = {'col1': [1, 2], 'col2': [3, 4]}
>>> df = pd.DataFrame(data=d)
>>> df.attrs = {1:1}
>>> df.attrs
{1: 1}
>>> df['col1'].attrs
{}

This would mean that any slicing operation would drop the attrs.
So if the user uses all the functions within the alchemlyb, there should be no problem, but if the user tried to do their own data slicing, the attrs would get lost.

[orbeckst]

We should add a section to the docs explaining that after user manipulation of dataframes, they need to apply the copy attr function.

Maybe @dotsdl has any ideas for the interface here.

Short of subclassing DataFrame to AlchemlybDataFrame I don't have a better idea.

[xiki-tempula]

I think the easiest way would be to drop the py36 support.
The support for py36 would be dropped in 6 months. The latest pandas version has already dropped support for py36 after 1.2.

[orbeckst]

I disagree with pandas — that's not good practice for scientific software.

[xiki-tempula]

I could write a decorator which checks if attr is present, and give a warning when it is absent for the estimator module.
The plotting uses the units.to_kT to do unit conversion, which could give the relevant error message.

Would mind merging the #131 so I could start working on this? Thanks.

[orbeckst]

@xiki-tempula so I think we'll drop Python 3.6 as you proposed here, at least judging by comments on #140 — please do weigh in and make your opinion known as a developer. Unlike dropping 2.7 and 3.5 support, that was not as clear cut of a decision for me and required some thought and weighing different arguments. Ultimately, I see that maintaining software longer than other parts of the ecosystem puts too much burden on voluntary developers. In the specific case here it also prevents us from using features that we need (or working with many ugly workarounds). So on balance, I can justify deprecating support for older versions more rapidly, as long as we communicate clearly what we do and make sure that there's a fairly stable release for any Python version near end of our support period.