Skip to content

Conversation

@jrbourbeau
Copy link
Member

This PR drops support for Python 3.7 and should be merged along with its companion PR over in dask/dask dask/dask#8572. Also see the related community conversation in dask/community#213

toolz >= 0.8.2
tornado >= 5;python_version<'3.8'
tornado >= 6.0.3;python_version>='3.8'
tornado >= 6.0.3
Copy link
Member

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

Comment on lines -6 to -12
if sys.version_info < (3, 8):
try:
import pickle5 as pickle
except ImportError:
import pickle
else:
import pickle
Copy link
Member

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 )

Copy link
Member Author

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+

Copy link
Member

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 🙂

Copy link
Member

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",
Copy link
Member

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?

Copy link
Contributor

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

Copy link
Member

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

Copy link
Member Author

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

@github-actions
Copy link
Contributor

github-actions bot commented Feb 2, 2022

Unit Test Results

       11 files   -        1         11 suites   - 1   6h 43m 49s ⏱️ - 16m 21s
  2 603 tests +       2    2 520 ✔️ +       9    79 💤  - 10  4 +3 
14 342 runs   - 1 216  13 344 ✔️  - 1 317  994 💤 +98  4 +3 

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.

Comment on lines 41 to 42
# Libraries exclusively imported under `if TYPE_CHECKING:`
- typing_extensions # To be reviewed after dropping Python 3.7
Copy link
Member

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?

Copy link
Member Author

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

Comment on lines -29 to -32
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
Copy link
Member

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

Copy link
Member

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.

Copy link
Collaborator

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

@jrbourbeau jrbourbeau changed the title [WIP] Drop Python 3.7 Drop Python 3.7 Feb 15, 2022
- types-setuptools
- types-psutil
# Libraries exclusively imported under `if TYPE_CHECKING:`
- typing_extensions # To be reviewed after dropping Python 3.7
Copy link
Collaborator

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

Copy link
Member

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes no problem

@jakirkham
Copy link
Member

Thanks James! 😄

@jakirkham jakirkham mentioned this pull request Feb 16, 2022
3 tasks
@crusaderky
Copy link
Collaborator

FAILED distributed/tests/test_worker.py::test_fail_write_to_disk - TypeError:...
FAILED distributed/tests/test_cancelled_state.py::test_value_raises_during_spilling
FAILED distributed/tests/test_spill.py::test_spillbuffer - assert 1247 == 698

please merge from main to fix

@jrbourbeau
Copy link
Member Author

Thanks @jakirkham @crusaderky -- planning to merge this and dask/dask#8572 later today if no further comment

@jakirkham
Copy link
Member

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.

@jakirkham jakirkham merged commit 60d82c2 into dask:main Feb 16, 2022
@jakirkham
Copy link
Member

Thanks James for the PR and everyone for the reviews! 😄

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 this pull request may close these issues.

5 participants