Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Not sure this is a good idea or not.

Motivation: we have too many fragmented traits, which are easy to forget to add in with() attrs.

Now __str__ will more looking like a normal #[pymethod]. But what it backs will be very different. It actually doesn't create a real pymethod, but actually creating slot_str. And __str__ will be placed by a slot-wrapper descriptor. After the patch, #[pymethod] fn __str__ will additionally create a pyslot for str.

This can be applicable to other single-method traits too.

Pros: Easy to understand. No worry to forget to add with() Cons: Confusing because it have different semantics comparing to other real pymethods.

Here are my concerns:

1. Will this lead to implementation difference with CPython where an entire CPython test suite will not be applicable? (so we will have to maintain our own)
2. I ain't so sure why __str__ was chosen for this PR while other dunder methods like __repr__ were not for example. This concern can be addressed with a detailed comment about this change

1. Will this lead to implementation difference with CPython where an entire CPython test suite will not be applicable? (so we will have to maintain our own)

No, this is a sort of developer interface. CPython test suites test the implementation. It doesn't matter if we use a trait or fake pymethod.

2. I ain't so sure why __str__ was chosen for this PR while other dunder methods like __repr__ were not for example. This concern can be addressed with a detailed comment about this change

Because this form is an alternative form of the trait approach, which is already implmemented for __repr__. If we use same approach for repr, then trait Representable will be replaced by #[pymethod] fn __repr__. So if we go this way, __repr__ will look like __str__ without trait Representable

I think it's a good idea to allow direct implementation unless protocols like Mapping or Sequence need to be implemented. Even from an AI (LLM) perspective, just implementing #[pymethod] fn __str__ seems less prone to mistakes.

There might be something like this, though. If you want to program at the Rust-level to only accept types that implement hash as input, like T: Hashable, traits would still be advantageous. However, I haven't done Rust-level extension programming with PyO3 or similar, so this is nothing more than a guess.

It feels a bit awkward to write #[pymethod] and have it automatically treated like #[pyslot] after previously distinguishing between #[pymethod] and #[pyslot], but I think everyone would expect __str__ written at the Rust-level to be a slot_str rather than wanting it to be treated as a built-in method or function.