drop support for python=3.9
#8937
Conversation
xarray/util/generate_ops.py
Outdated
| # We require a "hack" to tell type checkers that e.g. Variable + DataArray = DataArray | ||
| # In reality this returns NotImplementes, but this is not a valid type in python 3.9. | ||
| # In reality this returns NotImplemented, but this is not a valid type in python 3.9. | ||
| # Therefore, we return DataArray. In reality this would call DataArray.__add__(Variable) | ||
| # TODO: change once python 3.10 is the minimum. |
There was a problem hiding this comment.
@headtr1ck, can you explain (or directly push a fix, if possible) what you meant by this?
There was a problem hiding this comment.
I'm not sure if I will be able to code anytime soon, so here an explanation first:
If you do operators, python checks the left obj First. Since DataArray is an array-like (and therefore part of VariableCompatible), the type checker thinks that Variable + DataArray = Variable, which is incorrect.
If you want to follow the runtime behavior, you should return NotImplemented, unfortunately it is not a valid type in Python 3.9. Therefore we return DataArray directly.
Now the "fix" would be to change the return type to NotImplemented and check if it works in Python >=3.10 (I have not actually confirmed that, in case just leave things like they are since it is technically working).
|
This means we could replace |
Shouldn't pyupgrade / ruff do that for us? |
|
it does, but only parts of it (other fixes it deems unsafe so they require manual intervention). I don't have time to go through each of them this week, but feel to push any of these directly to this PR. |
Because of [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy) NumPy only supports ≥3.10 now. Also, Zarr, NetworkX, and ([soon](pydata/xarray#8937)) Xarray will support only ≥3.10.
|
I think delaying this until we have at least one release that is fully compatible with numpy2 and Python 3.9 is a good idea. Do we have an estimate on how much this would delay this merge? |
|
we have a numpy 2 + python 3.9 compatible release now, so once the merge conflicts are fixed this should be good to go |
It seems that there are still a few PRs open with fixes for numpy 2 and maybe we should wait a month or two to see if we get any bug reports related to that? I know that we are all eager to have more nice python things :) |
|
I think we should move forward here |
|
it looks like |
|
The tests failures are present on main too. |
dcherian
force-pushed
the
drop-python3.9
branch
from
26ebc0c to
c00ba1e
Compare
|
thanks for finishing this, @dcherian. Let's merge this now, and I'll update the list of required checks after that. |
* main: Revise (pydata#9366) Fix rechunking to a frequency with empty bins. (pydata#9364) whats-new entry for dropping python 3.9 (pydata#9359) drop support for `python=3.9` (pydata#8937) Revise (pydata#9357) try to fix scheduled hypothesis test (pydata#9358)
* main: (214 commits) Adds copy parameter to __array__ for numpy 2.0 (pydata#9393) `numpy 2` compatibility in the `pydap` backend (pydata#9391) pyarrow dependency added to doc environment (pydata#9394) Extend padding functionalities (pydata#9353) refactor GroupBy internals (pydata#9389) Combine `UnsignedIntegerCoder` and `CFMaskCoder` (pydata#9274) passing missing parameters to ZarrStore.open_store when opening a datatree (pydata#9377) Fix tests on big-endian systems (pydata#9380) Improve error message on `ds['x', 'y']` (pydata#9375) Improve error message for missing coordinate index (pydata#9370) Add flaky to TestNetCDF4ViaDaskData (pydata#9373) Make chunk manager an option in `set_options` (pydata#9362) Revise (pydata#9371) Remove duplicate word from docs (pydata#9367) Adding open_groups to BackendEntryPointEngine, NetCDF4BackendEntrypoint, and H5netcdfBackendEntrypoint (pydata#9243) Revise (pydata#9366) Fix rechunking to a frequency with empty bins. (pydata#9364) whats-new entry for dropping python 3.9 (pydata#9359) drop support for `python=3.9` (pydata#8937) Revise (pydata#9357) ...
Issue introduced by 16b53ac / pydata#8937. It looks like the `sys.version_info >= (3, 11)` test is incorrect, as `typing.TypeAlias` wasaAdded in version 3.10, not 3.11: https://docs.python.org/3/library/typing.html#typing.TypeAlias No conditional required for Python 3.10.
Issue introduced by 16b53ac / pydata#8937. It looks like the `sys.version_info >= (3, 11)` test is incorrect, as `typing.TypeAlias` was added in version 3.10, not 3.11: https://docs.python.org/3/library/typing.html#typing.TypeAlias
Issue introduced by 16b53ac / pydata#8937. It looks like the `sys.version_info >= (3, 11)` test is incorrect, as `typing.TypeAlias` was added in version 3.10, not 3.11: https://docs.python.org/3/library/typing.html#typing.TypeAlias
* Branches of the `if` statement have similar implementation Issue introduced by 16b53ac / #8937. It looks like the `sys.version_info >= (3, 11)` test is incorrect, as `typing.TypeAlias` was added in version 3.10, not 3.11: https://docs.python.org/3/library/typing.html#typing.TypeAlias * Branches of the `if` statement have similar implementation Introduced by 17933e7 / #7426.
According to our policy (and NEP-29) we can drop support for
python=3.9since about a week ago. Interestingly, SPEC0 says we could have started doing this about half a year ago (Q4 2023).We could delay this until we have a release that is compatible with
numpy>=2.0, though (numpy>=2.1will drop support forpython=3.9).whats-new.rst