-
Notifications
You must be signed in to change notification settings - Fork 22
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
Allowing Python 3.11 #278
Allowing Python 3.11 #278
Conversation
Other than making sure it is compatible, are there any new capabilities we would benefit from using? @michaelcdevin |
I don't see any new capabilities with Python 3.11 that we could use. 3.11 seems largely focused on speeding up CPython, and so we should see those benefits anyway since WecOptTool is already written in a pretty Pythonic fashion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to merge after you decide how to address my comments
README.md
Outdated
@@ -10,7 +10,7 @@ The Wave Energy Converter Design Optimization Toolbox (WecOptTool) allows users | |||
Refer to [WecOptTool documentation](https://sandialabs.github.io/WecOptTool/) for more information, including project overview, tutorials, theory, and API documentation. | |||
|
|||
## Getting started | |||
WecOptTool requires Python >= 3.8. Python 3.9 & 3.10 are supported. | |||
WecOptTool requires Python >= 3.8. Python 3.9 through 3.11 are supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may have had a conversation about this in the past where we decided we'd only support a finite number of Python versions (maybe 2) - should we change this to 3.10 & 3.11
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was 3. But I am OK with reducing it to 2 to make the CI quicker. We are usually one version behind the latest Python anyways, so 2 should be far behind enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I was wondering about how many versions we should support. 6c62be4 removes 3.9 as a supported version leaving only 3.10 and 3.11
.github/workflows/push.yml
Outdated
@@ -19,7 +19,7 @@ jobs: | |||
fail-fast: false | |||
matrix: | |||
os: ["ubuntu-latest", "macos-latest", "windows-latest"] | |||
python-version: ["3.9", "3.10"] # CHANGE: Python version | |||
python-version: ["3.9", "3.10", "3.11"] # CHANGE: Python version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As with below, maybe reduce to just 3.10 and 3.11 - this will also help keep the CI run times from getting too much longer.
Description
Python 3.11 has been out for almost a year and all of our dependencies now support it, so this changes our allowed Python versions. See #270.
Type of PR
Checklist for PR