-
-
Notifications
You must be signed in to change notification settings - Fork 750
Drop Python 3.7 #5683
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
Drop Python 3.7 #5683
Conversation
| toolz >= 0.8.2 | ||
| tornado >= 5;python_version<'3.8' | ||
| tornado >= 6.0.3;python_version>='3.8' | ||
| tornado >= 6.0.3 |
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.
This would also allow us to make the Conda package noarch again, which would help speed up building time in conda-forge
| if sys.version_info < (3, 8): | ||
| try: | ||
| import pickle5 as pickle | ||
| except ImportError: | ||
| import pickle | ||
| else: | ||
| import pickle |
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.
Now that pickle protocol 5 is builtin, it should be possible to drop all of the protocol=4 lines like those that were added here ( #4019 )
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.
Sorry @jakirkham, I missed this comment when you originally left it. I agree we probably don't need several of those protocol=4 anymore. That said, due to my bandwidth limitations I'd prefer to have those addressed in a separate PR. It would be good to have them cleaned up, but things will also work as-is on Python 3.8+
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.
Happy to pick up as a separate PR. Looking forward to pickle protocol 5 as the default 🙂
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.
Added draft PR ( #5826 ) with this change
| "Programming Language :: Python", | ||
| "Programming Language :: Python :: 3.7", | ||
| "Programming Language :: Python :: 3.8", | ||
| "Programming Language :: Python :: 3.9", |
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.
Should we add 3.10 here or do we want to do that separately?
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 requires separate effort: #5350 is still an issue
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.
Right I guess that depends what the scope is here. In the past we have sometimes dropped and added a Python version in the same PR because of special test cases, a range of package requirements, etc. that we still wanted covered. Dropping a Python version in those cases meant we lost that test coverage, but adding a new one at the same time meant we could redistribute that workload. Not sure if that applies here yet or not. Hence the question
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.
Should we add 3.10 here or do we want to do that separately?
I'd prefer to handle 3.10 support in a separate PR
Unit Test Results 11 files - 1 11 suites - 1 6h 43m 49s ⏱️ - 16m 21s For more details on these failures, see this check. Results for commit f1635dd. ± Comparison against base commit 6a17957. ♻️ This comment has been updated with latest results. |
| # Libraries exclusively imported under `if TYPE_CHECKING:` | ||
| - typing_extensions # To be reviewed after dropping Python 3.7 |
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.
Should the comment also be dropped?
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 catch -- just removed that comment
| from typing import TYPE_CHECKING, Any, ClassVar, Container | ||
| from typing import TYPE_CHECKING, Any, ClassVar, Container, Literal | ||
|
|
||
| if TYPE_CHECKING: | ||
| from typing_extensions import Literal |
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.
Is if TYPE_CHECKING: still needed here? It appears to be dropped elsewhere
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.
The other imports are python version independent and only needed for type checking but not for runtime.
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 protects what would otherwise be a circular import (which mypy deals with).
| - types-setuptools | ||
| - types-psutil | ||
| # Libraries exclusively imported under `if TYPE_CHECKING:` | ||
| - typing_extensions # To be reviewed after dropping Python 3.7 |
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.
This is needed again after #5814 as it uses TypeAlias
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.
Would it make sense to add in that PR?
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.
yes no problem
|
Thanks James! 😄 |
please merge from main to fix |
|
Thanks @jakirkham @crusaderky -- planning to merge this and dask/dask#8572 later today if no further comment |
|
Have seen macOS queuing for quite a while. This is happening on other PRs as well. Given as this passes elsewhere and there isn't anything macOS specific here (and is really just dropping things), going to go ahead and merge. Though if issues crop up on macOS, we can revisit. |
|
Thanks James for the PR and everyone for the reviews! 😄 |
This PR drops support for Python 3.7 and should be merged along with its companion PR over in
dask/daskdask/dask#8572. Also see the related community conversation in dask/community#213