API: Remove seterrobj/geterrobj/extobj= and related C-API functions
#23922
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
seberg
commented
Jun 12, 2023
| return 0; | ||
| } | ||
|
|
||
| #undef HANDLEIT |
There was a problem hiding this comment.
This is a straight copy paste, the only change is making them static.
|
@mattip I saw some of those unpacking non 0-d arrays into scalars in the f2py tests here also. Maybe something unrelated to the meson PR changed?! This run: https://github.com/numpy/numpy/pull/23922/checks?check_run_id=14193159921 (if it still is around) I don't think it is, so here the details: |
cc6b782 to
c3e2e57
Compare
…perr` We could introduce a new to combine these (mainly the GetPyValues and handlefperr) and we could do so in a way that is backwards compatible: Combine both functions into one small helper. There is no known user, but if someone comes up even restoring them should be possible. These functions are threaded through our code to deal with error handling but create an unnecessary `errobj` that may have made some sense when you wish to raise errors from a worker/inner-loop. However, we never do that, and there shouldn't a be reason for downstream to do that either: The current split in functions just makes it hard to improve the `errstate` handling (because this API will not remain useful internally).
This may slow things down very slightly, but we should be able to recover this easily and the `extobj=` API is a bit strange.
These are left for now as a private implementation detail.
We will want to undo parts because eventually we probably want to fetch the "global" relatively early on once and potentially thread it through in many places. But, that refactor probably needs to touch so much, that this should make it easier anyway.
We will remove some things without deprecations, this is a category for that.
|
I have dropped removal of Technically, the C-API could be retained. But I still think it will make the refactor unnecessarily annoying as it will require duplicate code for only that purpose and there is no known user. |
|
Thanks @seberg. Nice cleanup. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This has a couple of different commits and is unfortunately a bit large because of that. With the exception of the necessary linalg cleanup, they are rather intertwined though.
The commits should be cleanly reviewable one-by-one, though!
Not marking as draft, but the release note build may error until gh-23919 is merged.
Closes gh-23900. There were 2 👍 on the issue, so I assume/hope we have a consensus on these. Right now this is the most minimal useful version: Remove everything directly exposing
extobjor the C-API side tuple of(ufunc_name, callable)which is a weird indirection.EDIT: OK, removing "log" and "print" is not minimal.