➜
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.
Created on 2021-05-27 15:56 by DonnieODonnell, last changed 2022-04-11 14:59 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| diff.txt | DonnieODonnell, 2021-05-27 15:56 | git diff copy.py | ||
| Messages (3) | |||
|---|---|---|---|
| msg394558 - (view) | Author: Donald O'Donnell (DonnieODonnell) * | Date: 2021-05-27 15:56 | |
In copy.py of Std Lib, line 153 is now:
y = copier(memo)
Should be:
y = copier(x)
The present version copies the `memo` dict rather than `x`, the object to be copied by it's __deepcopy__ method.
|
|||
| msg394567 - (view) | Author: Zachary Ware (zach.ware) *  |
Date: 2021-05-27 16:55 | |
Do you have a short reproducer showing a behavioral bug here? That particular line of code hasn't changed in 19 years[1] :) [1] https://github.com/python/cpython/blame/main/Lib/copy.py#L153 |
|||
| msg394628 - (view) | Author: Zachary Ware (zach.ware) * |
Date: 2021-05-28 02:26 | |
Actually, looking into the implementation a bit, I can say there is definitely no bug here. Line 153 basically works out to `y = x.__deepcopy__(memo)`, which is how the `__deepcopy__` method is documented[1] to be called. Calling `copier(x)` instead would cause serious problems when a well-behaved `__deepcopy__` method then tries to call `deepcopy(self.some_attribute, memo)`. As such, I'm closing this issue as "not a bug". [1] https://docs.python.org/3/library/copy.html (see the last paragraph) |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:59:46 | admin | set | github: 88414 |
| 2021-05-28 02:26:08 | zach.ware | set | status: open -> closed resolution: not a bug messages: + msg394628 stage: resolved |
| 2021-05-27 16:55:04 | zach.ware | set | nosy:
+ zach.ware messages: + msg394567 |
| 2021-05-27 15:56:04 | DonnieODonnell | create | |