Use PyMethodsImpl instead of *ProtocolImpl::methods #917

kngwyu · 2020-05-09T08:19:30Z

To reduce specialization.
We have two kinds of protocol methods.

Slot methods. We have to set these methods to the type object. E.g., we have to set mp_length to enable len(obj).
Normal methods, called PyMethods in our proc-macro implementation.

For the later one, we don't need to use specialization. We can use the same trick as #[pymethods].

#897 should be merged before this PR.
I'll add CHANGELOG later to make rebasing easier.

kngwyu · 2020-05-09T08:25:59Z

guide/src/class.md

@@ -17,76 +17,7 @@ struct MyClass {
 The above example generates implementations for [`PyTypeInfo`], [`PyTypeObject`],
 and [`PyClass`] for `MyClass`.

-Specifically, the following implementation is generated:


I moved this code block to the last of the page.
It's too long for a user who doesn't have a strong interest in the implementation detail.

davidhewitt

Looking great, good to see ~400 lines reduction total!

One step closer to stable Rust 🎉

davidhewitt · 2020-05-09T19:32:12Z

pyo3-derive-backend/src/pyclass.rs

+/// To allow multiple #[pymethods] block, we define inventory types.
+fn impl_methods_inventory(cls: &syn::Ident) -> TokenStream {
+    // Try to build a unique type for better error messages
    let name = format!("Pyo3MethodsInventoryFor{}", cls);


Looking at the comment "The orphan rule disallows using a generic inventory struct..."

It might be possible now to achieve this, as Rust 1.41.0 relaxed orphan rules slightly: https://blog.rust-lang.org/2020/01/30/Rust-1.41.0.html#relaxed-restrictions-when-implementing-traits

So maybe we can have Pyo3MethodsInventory<MyClass>

What the above change made possible is impl<T> ForeignTrait<LocalType> for ForeignType<T>.
impl inventory::Collect for PyO3MethodsInventory<MyClass> is still impossible.

Ah yep you're correct 👍

davidhewitt · 2020-05-09T19:34:09Z

pyo3-derive-backend/src/pyproto.rs

@@ -57,53 +57,52 @@ fn impl_proto_impl(
    ty: &syn::Type,
    impls: &mut Vec<syn::ImplItem>,
    proto: &defs::Proto,
-) -> TokenStream {
-    let mut tokens = TokenStream::new();
+) -> syn::Result<TokenStream> {


davidhewitt · 2020-05-09T19:35:16Z

pyo3-derive-backend/src/pyproto.rs

-                                ml_doc: ""
-                            })
-                        }
+                // TODO(kngwyu): doc


davidhewitt · 2020-05-09T19:39:26Z

src/class/methods.rs

+}
+
+/// Implementation detail. Only to be used through the proc macros.
+/// Similar to `PyProtoMethodsImpl`, but for `#[pyproto]`.


"Similar to" looks wrong as it's listing the same type?

davidhewitt · 2020-05-09T19:44:17Z

src/pyclass.rs

@@ -73,7 +75,7 @@ pub unsafe fn tp_free_fallback(obj: *mut ffi::PyObject) {
 /// The `#[pyclass]` attribute automatically implements this trait for your Rust struct,
 /// so you don't have to use this trait directly.
 pub trait PyClass:
-    PyTypeInfo<Layout = PyCell<Self>> + Sized + PyClassAlloc + PyMethodsImpl
+    PyTypeInfo<Layout = PyCell<Self>> + Sized + PyClassAlloc + PyMethodsImpl + PyProtoMethodsImpl


I'm trying to understand - why is it necessary to make a new PyProtoMethodsImpl rather than using PyMethodsImpl for all of these?

Technically we can reuse PyMethodsImpl but I felt it easier to understand to have two inventory types corresponding to #[pymethods] and #[pyproto].
Not so string reason, though.

As this isn't a user-facing API, I guess the only people who need to understand it are us. I probably have a preference for just one inventory type so that there's less code overall to understand, but happy if you prefer to keep it as two.

I removed PyProtoMethodsImpl.

kngwyu force-pushed the pymethods-nodefault branch from 6738955 to b4f247f Compare May 9, 2020 08:21

kngwyu commented May 9, 2020

View reviewed changes

kngwyu added the blocked label May 9, 2020

davidhewitt reviewed May 9, 2020

View reviewed changes

kngwyu force-pushed the pymethods-nodefault branch from b4f247f to efbb414 Compare May 11, 2020 02:23

kngwyu changed the title ~~Introduce PyProtoMethodsImpl and remove *ProtocolImpl::methods~~ Use PyMethodsImpl instead of *ProtocolImpl::methods May 11, 2020

kngwyu force-pushed the pymethods-nodefault branch from efbb414 to 4f8bc0d Compare May 11, 2020 02:29

Use PyMethodsImpl instead of *ProtocolImpl::methods

69dba08

kngwyu force-pushed the pymethods-nodefault branch from 4f8bc0d to 69dba08 Compare May 11, 2020 11:08

kngwyu removed the blocked label May 11, 2020

kngwyu merged commit 3e61a58 into PyO3:master May 11, 2020

kngwyu deleted the pymethods-nodefault branch May 11, 2020 11:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use PyMethodsImpl instead of *ProtocolImpl::methods #917

Use PyMethodsImpl instead of *ProtocolImpl::methods #917

kngwyu commented May 9, 2020 •

edited

Loading

kngwyu May 9, 2020

davidhewitt May 9, 2020

davidhewitt left a comment

davidhewitt May 9, 2020

kngwyu May 10, 2020

davidhewitt May 10, 2020

davidhewitt May 9, 2020

davidhewitt May 9, 2020

davidhewitt May 9, 2020

kngwyu May 10, 2020

davidhewitt May 9, 2020

kngwyu May 10, 2020

davidhewitt May 10, 2020

kngwyu May 11, 2020

Use PyMethodsImpl instead of *ProtocolImpl::methods #917

Use PyMethodsImpl instead of *ProtocolImpl::methods #917

Conversation

kngwyu commented May 9, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidhewitt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kngwyu commented May 9, 2020 •

edited

Loading