-
Notifications
You must be signed in to change notification settings - Fork 802
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Remove ObjectProtocol #911
Conversation
Nice, thank you. I'll give a detailed review later.
Casting
Good catch 👍 , and I have another concern about borrow flags. #[pyclass]
struct Class {
field: usize
}
let ref_: PyRef<Class> = ~;
ref_.setattr("field", 5).unwrap(); So I think providing safe and good APIs for |
Oh, can you explain this to me? I thought because |
When a class with |
Hmm I think if casting let gil = Python::acquire_gil();
let py = gil.python();
let sub_any = PyCell::new(py, (SubClass {}, BaseClass { value: 120 })).unwrap().to_object(py);
let base_cell = sub_any.as_ref(py).downcast::<PyCell<BaseClass>>().unwrap();
println!("base: {:?}", base_cell as *const _);
let sub_cell = sub_any.as_ref(py).downcast::<PyCell<SubClass>>().unwrap();
println!("sub: {:?}", sub_cell as *const _);
// Output is the same address:
// base: 0x1f556db67f0
// sub: 0x1f556db67f0 |
We get access to You sure you don't want this? If you're sure, I am happy to change it to just |
Ah I missed that, sorry. So now we have two ways to get // 1.
let base = cell.borrow().into_super();
// 2.
let base: PyRef<Base> = PyCell::borrow(cell); Hmm... 🤔 |
Yeah, I would be glad to have ideas how to make the documentation better here. In my opinion this new way to borrow let cell: &PyCell<SubSubClass> = ...;
// Current way to get PyRef<Base>
// As one line: cell.borrow().into_super().as_ref()
let sub_sub_ref: PyRef<SubSubClass> = cell.borrow();
let sub_ref: PyRef<SubClass> = sub_sub_ref.into_super();
let base_ref: &PyRef<Base> = sub_ref.as_ref();
// New way to get PyRef<Base>
let base_ref: PyRef<Base> = PyCell::borrow(cell); |
Yeah, but I think simpleness is more important here than such kind of powerfulness, since it's rare to have grandparents. |
That's fair 👍 . I will change |
228d4d8
to
38a5edb
Compare
I've pushed that change 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost LGTM 👍
38a5edb
to
a5ebef4
Compare
I pushed a change to
|
Thank you! |
This is a reworked version of #892 which does not include the
builtin_methods
idea.Summary of changes:
ObjectProtocol
methods have been moved toPyAny
.Deref<Target = PyAny>
Changed so thatPyCell<T>
implementsDeref<Target = <T::BaseType as PyTypeInfo>::AsRefType>
. This allows deref to super types, and becausePyAny
is always the last base type, this meansPyCell<T>
can always access thePyAny
methods too. This actually provides a lot of the solution for A safe API for upcasting #787PyCell<T>
now just implementsDeref<Target = PyAny>
, thanks for feedback.I wanted to add
AsRef<PyAny>
toPyRef
andPyRefMut
, but this is more disruptive change because at the momentpy_ref.as_ref()
always gives the super type. If I add a secondAsRef
impl, then sometimes type inference fails where it did not before.I think I can improve that by creating
PyRef::as_super
, but still wanted to check what people think before I do that.