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