Following up to #4202 and #4206 I wanted to write down something I've been thinking about for a while. It looks like we're moving ahead with accepting those options so I'll assume that at least the design choice to have these options is accepted.
In summary, I think there are at least five convenience options to add to #[pyclass] to automatically expose Python magic methods based on Rust trait implementations:
Based off the recent PRs I think the basic implementation of these is more or less agreed upon, possibly excluding the extra argument on the string formatting options.
As we proceed with / make progress on the above, I think there are two further steps which make sense to explore:
- Simple enums currently generate
eq and repr automatically. I think we should be deprecating the automatic generation and start requiring opt-in to the new behaviour, to be consistent with everything else. I think it's relatively easy to do this as we just need to emit the deprecation warning if the eq or repr arguments weren't passed.
- I think a future extension would be to have
#[pyclass(init)] to automatically generate a constructor (like we already do for complex enums) and then #[pyclass(dataclass)] which does some or all of the above conveniences (maybe depending on whether the class is frozen).
Following up to #4202 and #4206 I wanted to write down something I've been thinking about for a while. It looks like we're moving ahead with accepting those options so I'll assume that at least the design choice to have these options is accepted.
In summary, I think there are at least five convenience options to add to
#[pyclass]to automatically expose Python magic methods based on Rust trait implementations:#[pyclass(eq)]for equality based offPartialEq- add pyclasseqoption #4210#[pyclass(ord)]for ordering operators based offPartialOrd- feat: Add 'ord' option for PyClass and corresponding tests #4202#[pyclass(hash)]for hash based offHash- add pyclasshashoption #4206#[pyclass(str)]for__str__based offDisplay. I think we could also have#[pyclass(str = "<format>")]to specify a format-args-compatible string concisely.#[pyclass(repr)]for__repr__based offDebug. Similarly to the above I think we could have#[pyclass(repr = "<format>")].Based off the recent PRs I think the basic implementation of these is more or less agreed upon, possibly excluding the extra argument on the string formatting options.
As we proceed with / make progress on the above, I think there are two further steps which make sense to explore:
eqandreprautomatically. I think we should be deprecating the automatic generation and start requiring opt-in to the new behaviour, to be consistent with everything else. I think it's relatively easy to do this as we just need to emit the deprecation warning if theeqorreprarguments weren't passed.#[pyclass(init)]to automatically generate a constructor (like we already do for complex enums) and then#[pyclass(dataclass)]which does some or all of the above conveniences (maybe depending on whether the class isfrozen).