Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for python 3.8 #1315

Closed
drvinceknight opened this issue Apr 8, 2020 · 6 comments · Fixed by #1366
Closed

Add support for python 3.8 #1315

drvinceknight opened this issue Apr 8, 2020 · 6 comments · Fixed by #1366

Comments

@drvinceknight
Copy link
Member

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.

@meatballs
Copy link
Member

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.

@marcharper
Copy link
Member

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.

@meatballs
Copy link
Member

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

@drvinceknight
Copy link
Member Author

drvinceknight commented Jul 3, 2020

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).

@meatballs
Copy link
Member

I never write a class without using attrs any more!

@marcharper
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants