-
Notifications
You must be signed in to change notification settings - Fork 113
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
convert PyUntypedArray
to Bound
API
#411
Conversation
Should we be changing the PyO3 deref implementation to make it possible for downstream to decide the target type? This might be relevant in class hierarchies, for example. Alternatively we could experiment with removing the deref-to-pyany blanket and instead implement |
I guess the problem with doing that is that things like |
It might be a good idea experimenting with that. I don't think it would be a huge deal here, nice to have, but not a deal breaker either. Maybe we can add an associated type to |
So, given that the deref idea doesn't work out, I guess that the design as proposed here is the right way to proceed? |
Yes, I just did not find time to complete the review here yet. |
No problem, I have also had a disrupted week. I'm hoping to go through the list of actions for 0.21 and see what remains before the final release later. |
Following #410
This migrates
PyUntypedArray
to theBound
API. This introducesPyUntypedArrayMethods
to implement the methods onBound<PyUntypedArray>
. Additionally this also implements the trait onBound<PyArray<T, D>>
, viaas_untyped
, because we will not be able to provide aDeref
implementation anymore, due to orphan rules and the deref toBound<PyAny>
. This seemed like the most reasonably option to keep the same ergonomics.