This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Document structure of memo dictionary to enable more advanced __deepcopy__ uses
Type: Stage: resolved
Components: Documentation Versions:
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, josh.r, r.david.murray
Priority: normal Keywords:

Created on 2017-09-18 20:05 by josh.r, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (2)
msg302485 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2017-09-18 20:05
At present, the documentation for the copy module doesn't document anything about the memo dictionary for deepcopy except to say that it must be received by custom __deepcopy__ methods and passed along when calling copy.deepcopy, and that it is a "dictionary of objects already copied during the current copying pass", without specifying what the keys or values are.

Without providing a documented meaning for the keys and values in the memo dict, it's impossible to use it in a supported way for more complex cases (e.g. a case where the object must be created partially and memoized prior to deepcopying attributes that can self-reference). For an example, see this StackOverflow answer's approach to using __deepcopy__:

Officially, the line where it does:

memo[id(self)] = newself = self.__class__(copy.deepcopy(, memo))

is not using documented behavior AFAICT; the fact that the memo dict maps id()'s of the original objects to the new instance is undocumented. This wouldn't be so bad if there were a documented way to achieve the desired result, but in recursive cases like these it's the only way to add deepcopy support without also adding pickle support.

I'd suggest documenting the current behavior, assuming the current behavior is consistent on all alternate Python implementations; I know id() is a little funky elsewhere, but I'm not sure there is any other sane implementation.
msg302486 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-18 20:24
Unless I'm mistaken (and someone will correct me and reopen the issue if I am :) it is intentionally undocumented.  A proposal for a documented protocol of some sort is certainly a possibility, but is something that should start with a discussion on the python-ideas mailing list.
Date User Action Args
2022-04-11 14:58:52adminsetgithub: 75694
2017-09-18 20:24:48r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg302486

resolution: not a bug
stage: resolved
2017-09-18 20:05:46josh.rcreate