Axelrod-Python/Axelrod

Add support for python 3.8

drvinceknight opened this issue ยท 6 comments

This requires modifying https://github.com/Axelrod-Python/Axelrod/blob/master/.github/workflows/config.yml#L13:

        python-version: [3.6, 3.7]

to become:

        python-version: [3.6, 3.7, 3.8]

And also modifying setup.py to reflect that 3.8 is also supported: https://github.com/Axelrod-Python/Axelrod/blob/master/setup.py#L31

I had a quick try and some tests failed. I know that the library works on 3.8 so it's just a question of figuring out what needs to be tweaked. I don't expect this to be a big thing.

@marcharper suggested dropping 3.6 I'd suggest that unless there is something that 3.6 support is stopping us from doing then we should keep it.

If we decide to drop 3.6 then we need to modify setup.py (the lower bound of python) but also the README.

We did say some while back that we'd support the current python version and one prior, so dropping 3.6 would fit that policy.

However, that was as a result of wanting to use features that only came in with 3.6. I don't think we've wanted to use dataclasses or a walrus operator yet, so there isn't the same pressure to drop 3.6.

We should perhaps change the policy (not sure if it's written anywhere) to be explicit about the python version we support - currently 3.6 and 3.7, about to become 3.6, 3.7 and 3.8.

I'd like to start using data classes, which is a reason to drop 3.6. (See #1353 and the dataclasses I just added on the testing branch if curious why.) The failing tests for 3.8 are due to hypothesis and one of the changes in 3.8 (see here). We use an ancient version of hypothesis and the issue is fixed in more recent versions.

I'm updating our use of hypothesis in #1288, after which we should be fine to enable 3.8. Alternatively we could start using the attrs library, which @gaffney2010 is a fan of, and has similar (better even) functionality than the standard library data classes.

Python 3.9 is scheduled for October (~4 months) and we can support 3 trailing versions at that time.

We could use attrs instead of data classes. It has more capabilities and is more or less the standard these days.

I can't say I know enough about attrs and/or data classes to have a helpful opinion here (I really should go learn about them). But if it's decided that we need to drop 3.6 to be able to use one or the other I'm fine with it.

One [minor] point about hypothesis: they move fast over there (or at least they used to) and our CI would often break when they updated. Not at all against pushing forward to a less ancient release but I'd still suggest we pin the specific version we end up with (for the immediate future).

I never write a class without using attrs any more!

Ok great. I'll pin hypothesis at 5.19 for now as I'm fixing tests, and we can use dataclasses / attr for now. Unfortuantely neither approach has great serialization, so I'm using YAML on top of dataclasses for now, but it would be easy to switch to attrs if we want.