-
Notifications
You must be signed in to change notification settings - Fork 760
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
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.