docs: show pattern for self.__class__.__name__ in __repr__

[wjones127]

It took me a little while to figure out this pattern in PyO3, so I thought it would be a good addition to the guide.

It's not the cleanest pattern, so would welcome suggestions on how to make it shorter or easier.

[adamreichold]

Thank you for sharing your findings! I agree that it is not obvious how to approach this. However, I would suggest not burdening this particular example with the complication but to start a new example on how to access the class name.

Concerning the implementation, instead of starting with PyRef, I think it would simpler to use PyCell which is the actual shape of the Python object and therefore directly derefs into PyAny creating another strong reference, e.g.

diff --git a/guide/src/class/object.md b/guide/src/class/object.md
index 357fdcd7..5b099ed3 100644
--- a/guide/src/class/object.md
+++ b/guide/src/class/object.md
@@ -53,13 +53,17 @@ contained inside `Number`.
 impl Number {
     // For `__repr__` we want to return a string that Python code could use to recreate
     // the `Number`, like `Number(5)` for example.
-    fn __repr__(&self) -> String {
+    fn __repr__(self_: &PyCell<Self>, py: Python<'_>) -> PyResult<String> {
+        let class_name: String = self_
+            .getattr("__class__")?
+            .getattr("__name__")?
+            .extract()?;
         // We use the `format!` macro to create a string. Its first argument is a
         // format string, followed by any number of parameters which replace the
         // `{}`'s in the format string.
         //
         //                       👇 Tuple field access in Rust uses a dot
-        format!("Number({})", self.0)
+        Ok(format!("{class_name}({})", self_.borrow().0))
     }
 
     // `__str__` is generally used to create an "informal" representation, so we

However, for this particular issues (getting the name of Rust-implemented Python class), there is simpler way IIUC via our own PyTypeInfo trait, e.g.

diff --git a/guide/src/class/object.md b/guide/src/class/object.md
index 357fdcd7..c2d0865f 100644
--- a/guide/src/class/object.md
+++ b/guide/src/class/object.md
@@ -44,7 +44,7 @@ It can't even print an user-readable representation of itself! We can fix that b
 contained inside `Number`.
 
 ```rust
-# use pyo3::prelude::*;
+# use pyo3::{prelude::*, PyTypeInfo};
 #
 # #[pyclass]
 # struct Number(i32);
@@ -59,7 +59,7 @@ impl Number {
         // `{}`'s in the format string.
         //
         //                       👇 Tuple field access in Rust uses a dot
-        format!("Number({})", self.0)
+        format!("{}({})", Self::NAME, self.0)
     }
 
     // `__str__` is generally used to create an "informal" representation, so we

which I would probably prefer to show case. But I am not sure whether we want to guide user's towards these "infrastructure traits" too strongly?

[birkenfeld]

The second one is also incorrect in subclasses.

But couldn't the lookup of class and name be done faster with native APIs? self.get_type().name()?

[adamreichold]

But couldn't the lookup of class and name be done faster with native APIs? self.get_type().name()?

Indeed! But you'd still have to go via PyCell<Self> to access PyAny::get_type, e.g. self_.get_type().name(), right?

[davidhewitt]

But I am not sure whether we want to guide user's towards these "infrastructure traits" too strongly?

I would be in favour of not doing so, I have been pondering a move of PyTypeInfo::NAME and PyTypeInfo::MODULE to PyClassImpl, so I'd prefer not encourage users to access those members :)

(While NAME is probably reasonable to have there, I don't see a clear need for it given runtime access is more reliable. MODULE is likely unhelpful because it's not even required to be populated, and types are often accessed via a public API module which isn't where they're actually defined.)

[adamreichold]

I would be in favour of not doing so, I have been pondering a move of PyTypeInfo::NAME and PyTypeInfo::MODULE to PyClassImpl, so I'd prefer not encourage users to access those members :)

Ok, so I think the consensus so far is:

• Use a separate example, specifically on the topic "access the Python-level class object of Rust-defined #[pyclass]".
• Use &PyCell<Self> as the receiver as it directly derefs to PyAny.
• Use the native methods like PyAny::get_type instead of access attributes by name.

[wjones127]

Thanks for the advice. Btw #1059 would still be really useful; I had no idea you could take &PyCell<Self> as a parameter. If I understood this better right now I would write it myself.

[adamreichold]

LGTM, let's give it a while for others to have a look and if there are no objections we can merge. Thanks again for taking the time to improve the docs!

[mejrs]

LGTM, just a small nit

[adamreichold]

@wjones127 Could you squash your commits before merging? Thanks.

[adamreichold]

bors r+

[bors]

Build failed:

• conclusion

[adamreichold]

I force-pushed to remove the usage of inline format arguments.

bors r+

[bors]

Build succeeded:

• conclusion