-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
run CI on python=3.12
#8605
run CI on python=3.12
#8605
Conversation
keewis
commented
Jan 12, 2024
- Closes add py3.12 CI and update pyproject.toml #8580
@Illviljan, it appears on from xarray.namedarray._typing import _arrayfunction
import pint
ureg = pint.UnitRegistry()
q = ureg.Quantity([0, 1, 2], "m")
isinstance(q, _arrayfunction) # True on `python < 3.12`, False on `python=3.12` I assume this is due to the caveat about the performance improvements in this section? Do you have any idea what we have to do to fix this (here or in Edit: |
as it turns out, my edit above is wrong: |
Was the dtype fix in pint enough to solve all the errors, @keewis? I didn't go through all the errors but a few seems to be due to triggering a reduction like xarray/xarray/namedarray/core.py Line 800 in d20ba0d
Because That's my high level point of view at least... I've been looking into |
yes, that was enough to fix every issue (at least on my machine, not entirely sure about windows / macos). To unblock this we decided in the meeting today to remove
We need to be careful about removing runtime checks, as this can easily become unsafe – though if we can ensure for normal usage that we don't work on data that has never been checked I would agree, checking more than once is not necessary. As an example for when this can go wrong, |
The reason is that `pint` currently does not explicitly define `dtype`, causing our runtime checkable protocols not to match.
Unfortunately not true for our lazy indexing wrappers. EDIT: I guess those live in |
My point of view here is technically NamedArray hasn't 'removed' any runtime checks as it's not public yet. Now NamedArray has a performant initialization with the promise that the user inputs a valid array function or array api. If the user is uncertain about the data, then use the slower
The lazy wrappers needs more love to be considered array_functions/array_api is what I'm reading! |
As long as that was a intentional decision with runtime usage in mind I'm fine with the current state. |