Repository navigation
API: Slash down errstate related API to make it sustainable #23900
Description
For NumPy 2.0 (or well, TBH, I think we could also pull this off in a normal release, but then I might ask for a brief NEP, because I want to jump deprecations), I would like:
- Delete any weird "log" and "callback" stuff from the errobj/errstate
- Remove
seterrobj,geterrobj,seterrcall,geterrcalland the ufuncerrobj=- I would add an error on the last one with a note that we are willing to accept patches to restore some of its behavior if there is a real need. I don't hate allowing passing this state in, but I think it should evolve (and probably have a new name).
geterr()andseterr()are OK, since they take/return dicts.errstateis preferable, but they don't matter for this. (I am OK with removing them, but I think just deprecating them is also fine.)
errobj is a weird mutable list, I don't think using it is good and I suspect it will just make fixing the errstate hard.
Now the callback is probably used a couple of time in the wild, I found this: https://github.com/aglavic/genx/blob/8083fb73271f24dbf8c92433a6a86b422fefede5/genx/genx/core/custom_logging.py#L80
I think it should be fine (and backwards compatible) to ask such programs to monkey-patch warnings.showwarning instead.
Can I get a few 👍 for this change? :)
EDIT: Whooops, the ufunc keyword argument is called extobj not errobj, shows how much its used ;).
Activity
seberg commentedon Jun 8, 2023
SciPy does not use any of these but
numpy.linalgdoes. We could replace it with a try/except and thewith errstate(). That is slightly noticeable in speed (<2.5us of 10us for a single 3x3 inverse) due to theerrstateoverhead and slightly ugly.Maybe starting with
seterrobjandgeterrobjwill be easier. Although, I doubt the slowdown is bad enough to worry about (and can probably be slashed down in an eventual follow-up).seberg commentedon Jun 9, 2023
This also requires ripping out the C-API functions
PyUFunc_GetPyValuesandPyUFunc_handlefperr.They are designed in an awkward way to allow use within a ufunc inner-loop. Something that we don't do (presumably anymore). I have not found any usage of them.
If people speak up with need, we (or rather they) could add the new
PyUFunc_GiveFloatingpointErrorsto the public API with backport. The function squashes both versions.seberg commentedon Jun 9, 2023
Basically, the proposal is now:
Remove the C-API functions and at least
(set|get)errobjas well as theerrobj=kwarg.np.errstate()supports everythinglinalgneeds. The only caveat is overhead and I am sure that this can (and would presumably) be reduced by at least a factor of 2: it's fine.Additionally, I would think it is a good idea to slash the API more, because few use it anyway:
seterr,seterrcall,setbufsizecould be folded into something likenp.errstate(...).apply(). (Occasionally it is useful to set things globally; this would discourage that as well as reduce API.)geterr,geterrcall, andgetbufsizecould also be attributes onnp.errstate(). I think that makes sense: they are probably practically never used, but no introspection capability would be weird.Those changes are:
seterrwill be used mainly, most of which should just switch toerrstateanyway. A few people who set it globally may need a try/except hack. (If anyone worries about that, or people complain, we could keepseterraround or add it back.)(The C-API change is in theory higher impact. But its hard to see why anyone needs to align with our machinery and we should be able to add work-arounds in the off-chance that someone complains. Plus, there are no known users, so it wouldn't matter even if it was higher impact.)
EDIT: I will add removing of
logandprint. For no particular reason beyond thatcallshould be enough tologin practice and thatprintto stdout is weird and the only point for it is avoiding grabbing the GIL (which doesn't make sense in our use of this).mattip commentedon Jun 11, 2023
+1 for the cleanup. I would like to move to a contextvar as well