Open jcea opened 1 week ago
The same issue happens with pickle.Pickler.persistent_id
:
Python 3.12.7 (main, Oct 3 2024, 03:21:52) [GCC 10.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pickle import Pickler
>>> a=Pickler(open('/dev/zero'))
>>> a.persistent_id=lambda x: x
>>>
Good so far.
But in Python 3.13.0:
Python 3.13.0 (main, Oct 9 2024, 14:54:06) [GCC 10.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pickle import Pickler
>>> a=Pickler(open('/dev/zero'))
>>> a.persistent_id=lambda x: x
Traceback (most recent call last):
File "<python-input-6>", line 1, in <module>
a.persistent_id=lambda x: x
^^^^^^^^^^^^^^^
AttributeError: '_pickle.Pickler' object attribute 'persistent_id' is read-only
>>>
It seems related to bug #89850 and PR #113579.
@serhiy-storchaka, Could you possibly verify this? Thanks.
Yes, this is a consequence of the #89850 change. I missed such use case because there were no tests for it. You still can override attributes of instances of subclasses.
The proposed fix adds managed dicts to these classes (I would add simple instance dicts, but it is easier to add managed dicts). This may open a can of worms, because you can now set arbitrary attributes of instances of these classes. There will be no way to close it. But I think this is the only way to make this working while keeping super()
working too.
What about restoring the property support (get/set) for those two attributes?
It could even support "delete" to reactivate current configuration, although I don't think that anybody overwriting "persistent_id" or "persistent_load" would be interested in that.
This would be very complex solution and it would not work with super()
.
But we can make attributes (and only these attributes) writable by implementing tp_getattro
and tp_setattro
. This is slightly more complex solution, but not extremely complex. See #125752.
Bug report
Bug description:
In Python releases previous to 3.13, the following code used to work (this idiom is used in Durus and ZODB persistence systems):
Fine so far.
In Python 3.13, this doesn't work anymore:
I don't know if this is an intended change or a regression.
PS: The subclass approach works:
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs