Closed JRRudy1 closed 1 month ago
Please add a test -- they're not just to ensure that this implementation is correct (and I agree, it looks trivial), they're also to ensure that as we refactor and change our APIs in the future, we don't break this.
Please add a test -- they're not just to ensure that this implementation is correct (and I agree, it looks trivial), they're also to ensure that as we refactor and change our APIs in the future, we don't break this.
No problem, done!
Actually something failed, sorry I'll fix it.
Thanks
No problem, thanks for the merge!
This is a tiny change that allows
Bound<T>
to be returned from a pyclass's#[new]
method, as is already supported forPy<T>
.This flexibility would be convenient in certain cases; for example, it is often desirable to have a constructor for use on the Rust-side that returns the type as a Python object (
Py<T>
orBound<T>
) instead ofT
directly (e.g. when you want to be able todowncast
intoT::BaseClass
). And as long your desired arguments are the same as for your#[new]
method, you can just reuse the same constructor for use from both Python and Rust. However, you are currently limited to getting aPy<T>
from this, which usually has to be followed by.into_bound(py)
if you want to do anything useful with it. But if you could have the#[new]
method returnBound<T>
instead, as implemented by this PR, then it would be more ergonomic to call from Rust (while making no difference on the Python side). I also think it just makes sense intuitively, sinceBound<T>
is essentially justPy<T>
with superpowers.In my opinion this change is too trivial to warrant adding tests, but let me know if you disagree and I can add some.