New submission from Josh Rosenberg: 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__: https://stackoverflow.com/a/46284091/364696 Officially, the line where it does: memo[id(self)] = newself = self.__class__(copy.deepcopy(self.id, 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. ---------- assignee: docs@python components: Documentation messages: 302485 nosy: docs@python, josh.r priority: normal severity: normal status: open title: Document structure of memo dictionary to enable more advanced __deepcopy__ uses _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31513> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
