Conversation
Codecov Report
Additional details and impacted files
|
|
From the deprecation notice,, it seems to me that we should be using the Numba-aliased errors. I replaced our changes to I also therefore am mixing import styles, but I think in time we are moving to |
numba.core.errors.Numba<Error> instead of Error in a Numba typing context.
|
I'm not really sure what the intended difference is between >>> issubclass(numba.TypingError, numba.NumbaError)
True
>>> issubclass(numba.NumbaTypeError, numba.NumbaError)
TrueOh, it turns out that >>> numba.TypingError.mro()
[<class 'numba.core.errors.TypingError'>, <class 'numba.core.errors.NumbaError'>, <class 'Exception'>, <class 'BaseException'>, <class 'object'>]
>>> numba.NumbaTypeError.mro()
[<class 'numba.core.errors.NumbaTypeError'>, <class 'numba.core.errors.TypingError'>, <class 'numba.core.errors.NumbaError'>, <class 'Exception'>, <class 'BaseException'>, <class 'object'>]I'm on board with @ianna, what do you think? |
ianna
left a comment
There was a problem hiding this comment.
I like it, it is more expressive. Thanks!
|
Okay, then I'll merge! |
This is the only update needed to pass tests with Numba 0.58.0rc1. However, that version of Numba still raises a warning if
export NUMBA_CAPTURED_ERRORS=new_styleis not explicitly set (should probably be changed in Numba itself). Most of the exceptions changed were
TypeErrors, but a few wereValueErrorsthat really ought to have been type errors. (Not finding a record field by name is a type error in compiled code.)Vector is already up-to-date with respect to
TypeErrorversusnumba.TypingError.