Changes between Initial Version and Version 1 of Ticket #15692, comment 23


Ignore:
Timestamp:
08/24/15 19:27:40 (6 years ago)
Author:
nbruin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #15692, comment 23

    initial v1  
    11Replying to [comment:22 saraedum]:
    22> Do you have any idea how I could implement that? I could for example implement {{{__getstate__}}} for sage parents and elements, but then whenever it is overwritten I would have to rely on the super implementation being called.
     3
     4(I'm pretty sure that `__getstate__` should call its super unless one really knows what one is doing. A bigger problem is that `__getstate__` is only a convention that the standard `__reduce__` uses. I'm sure there are classes that implement their own `__reduce__` far below the point where you'd be thinking of injecting your `__getstate__`)
    35
    46On #15207 there is some discussion of some possible infrastructure for managing these things. Perhaps it's relevant for your case?
     
    1113
    1214If this is not appropriate behaviour, it seems to me that the class has rather special needs and hence should provide its own `__copy__`.
     15
     16'''EDIT:''' I see that `ClearCacheOnPickle` gets its `copy` behaviour because under certain circumstances, `copy(...)` will revert to calling `__getstate__`. So I would expect that this would continue to be the case.  Since the "clear cache on copy" is a bit of a side-effect of the implementation of `ClearCacheOnPickle` I would try and see if just changing the copy behaviour gives acceptable results. If not then providing a custom `__copy__` on just the class that originally inherited from `ClearCacheOnPickle` would do the trick. Going forward, I think having caches replicated (or probably even shared!) between shallow copies by default doesn't seem like an unreasonable default.