Align __post_init__ behaviour after copy.copy / copy.deepcopy / copy.replace with dataclasses
#933
Conversation
|
There is no need to call While testing the behaviour of msgspec.Structs vs dataclasses, I just noticed something odd, namely that Testscript.py: import copy
from dataclasses import dataclass, replace
import msgspec
@dataclass
class D:
x: int
def __post_init__(self):
print(" - dataclass: post init called")
class M(msgspec.Struct):
x: int
def __post_init__(self):
print(" - msgspec: post init called")
print("Construct objects")
d = D(1)
m = M(1)
print("Test replace")
d2 = replace(d, x=2)
m2 = msgspec.structs.replace(m, x=2)
print("Test copy.copy()")
d3 = copy.copy(d)
m3 = copy.copy(m)
print("Test copy.deepcopy()")
d4 = copy.deepcopy(d)
m4 = copy.deepcopy(m)Output: |
|
Is there a compelling reason to call that upon a deep copy? If not, then I'd prefer to also fix that in this PR. |
None that I can think of. Mirroring dataclass behaviour seems to be sensible, however, removing this |
|
I think breaking changes are fine since we are still sub-1.0 and we're also going to introduce others like #790. Both will come in the next minor release. |
I'll update this PR accordingly then |
2ff3752 to
8983373
Compare
__post_init__ after replace()__post_init__ behaviour after copy.copy / copy.deepcopy / copy.replace with dataclasses
8983373 to
c2ae730
Compare
| } | ||
|
|
||
|
|
||
| static PyObject* get_deepcopy_func() { |
There was a problem hiding this comment.
Trying a new style of handling these kinds of imports here. We initialize the field on the module state as NULL, and import on an as-needed basis. I think this is a fairly reasonable compromise between performance and complexity. After the first import, it's just one additional x == NULL check, which should be negligible in terms of performance.
The only real downside I can see is that you now have got to remember to use the "getter function" and cannot rely on the module state.
@ofek lmk what you think about this.
There was a problem hiding this comment.
copy is a very cheap import (~200us on my machine), and is used by so many modules in the stdlib and downstream that delaying its import doesn't feel worth it (for example, the python repl in 3.13 will import it on startup). Maybe a useful pattern for other modules, but I'd just import this one at startup and avoid the complexity.
There was a problem hiding this comment.
I agree that we should not lazily import this module however I think your implementation would be extremely useful for basically everything else, if you wouldn't mind trying or documenting the pattern somewhere for a future PR?
There was a problem hiding this comment.
if you wouldn't mind trying or documenting the pattern somewhere for a future PR?
Yeah, that was my goal. I wanted to use this opportunity to test out this pattern. I was planning to make a follow up PR using this for the re module, where I think it might be worth it. I'll move this implementation over there.
for basically everything else
I think the typing module will also always be imported no matter what, so it wouldn't be as useful there.
c2ae730 to
7b06643
Compare
|
Friendly ping to @ofek for a review :) |
Fix #874.
Align Struct's
__post_init__behaviour with that of dataclasses, when created bycopy.copy/copy.deepcopy/copy.replace.__post_init__oncopy.replace/__replace__oncopy.copy/copy`oncopy.deepcopy/deepcopy`This is a breaking change in behaviour, as structs intentionally did not call
__post_init__after a__replace__operation. However, as this diverges from dataclass behaviour, it's probably the right thing to do.To achieve the desired
copy.deepcopybehaviour, I had to implement a new__deepcopy__method (previously structs did not define a custom__deepcopy__.An open question though is how to behave in the case of a__copy__operation. Currently,__post_init__isn't called there either. Intuitively, it would make sense for__copy__and__replace__to behave the same in regards to__post_init__, as they're similar operations (both create a new instance from an existing instance of the same type).