You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been looking forward to the cuda bindings for a while, and was just looking through the docs.
The overview notes an implementation of ASSERT_DRV, which already contains the caveat:
In a future release, this may automatically raise exceptions using a Python object model.
I'm not sure if that means that the errors are going to be subclasses of something like a CUDAError, or if that is to be interpreted some other way, but in any case, I was quite surprised about this choice of exception API
Why not make the functions raise err by default? Right now, IIUC, every invocation would need to accept an extra err-return (and handle it with something like ASSERT_DRV). This seems like a really onerous task to achieve the default behaviour of "fail in case of something unexpected" (and actively choosing where to introduce try... except: handling to continue even if things fail).
It seems like a bad trade-off for me (high verbosity, and easy to forget adding an ASSERT_DRV), but maybe I'm overlooking something?
The reasons I'm raising this right now, is that this would be a pretty fundamental API change, and if there's any chance at all (assuming it's not already "zero" after GA), it would be ASAP.
The text was updated successfully, but these errors were encountered:
There will be a higher-level "object oriented" API on top of the current CUDA Python bindings, which will raise exceptions on errors. For efficiency reasons, and to match the C API as closely as possible, the lower level bindings return error codes.
Thanks for the quick response @shwina, proximity to the C-API is something understandable, and I'm very happy to hear that "this may automatically raise exceptions using a Python object model" should be interpreted as an entire higher-level API layer. 馃槉
(though perhaps that plan could be delineated more clearly in the overview 馃檭)
Congratulations on the GA release! 馃コ
I've been looking forward to the cuda bindings for a while, and was just looking through the docs.
The overview notes an implementation of
ASSERT_DRV
, which already contains the caveat:I'm not sure if that means that the errors are going to be subclasses of something like a
CUDAError
, or if that is to be interpreted some other way, but in any case, I was quite surprised about this choice of exception APIWhy not make the functions raise
err
by default? Right now, IIUC, every invocation would need to accept an extraerr
-return (and handle it with something likeASSERT_DRV
). This seems like a really onerous task to achieve the default behaviour of "fail in case of something unexpected" (and actively choosing where to introducetry... except:
handling to continue even if things fail).It seems like a bad trade-off for me (high verbosity, and easy to forget adding an
ASSERT_DRV
), but maybe I'm overlooking something?The reasons I'm raising this right now, is that this would be a pretty fundamental API change, and if there's any chance at all (assuming it's not already "zero" after GA), it would be ASAP.
The text was updated successfully, but these errors were encountered: