Conversation
…methods @struct builds a new class and copies the decorated class's namespace into it, so the __class__ cell of the copied methods still pointed at the discarded class. Rebind that cell to the returned class, as dataclasses does for slots=True.
ZeroIntensity
left a comment
ZeroIntensity
left a comment
There was a problem hiding this comment.
This fix looks really fragile and relies on a lot of internals. I don't have any alternative ideas yet, but it would be good to look at how other libraries handle this (for example, what do attrs and pydantic do?).
@johnslavik, I think you might find this one interesting. It reminds me of your NamedTuple work from a while back.
| import sys | ||
|
|
||
| from dataclasses import dataclass | ||
| from dataclasses import dataclass, _update_func_cell_for__class__ |
There was a problem hiding this comment.
I think it's a really bad idea for us to rely on dataclass internals like this.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
I don't think they have to do anything as they don't replace the original class with a synthetic one. |
3 participants
Methods of a
@ctypes.util.structclass keep a__class__cell that points at the original class, so zero-argumentsuper()raisesTypeErrorand__class__names the wrong class. The decorator now rebinds that cell to the class it returns, the same waydataclassesdoes forslots=True.No NEWS entry:
ctypes.util.structis new in 3.16 and has not been released.super()raisesTypeErrorin actypes.util.structmethod #158418