Message247156
If PyObject_RichCompareBool() reports that a key is already present in the set, then set_add_entry() is under no further obligation to make an insertion. As long as there is no risk of segfault, there is no more obligation to cater to lying or self-destructing __eq__ methods than there is to support objects that return randomized __hash__ values.
The docs for set.add(...): "Add an element to a set. This has no effect if the element is already present." The latter condition is determined by the PyObject_RichCompareBool() check. If it reports a match, then it is reasonable to do nothing.
FWIW, dicts don't have a choice in this regard because they still have an implementation that depends on returning a currently valid entry which they can't do if the table is mutating during the search. The set_add_entry() implementation has the advantage in that it is self-contained and need only report -1 is an error arose during the comparison or a 0 to indicate that no error arose. Also, note that sets diverged from dicts that the outset in that they don't swallow exceptions like PyDict_GetItem() does. |
|
Date |
User |
Action |
Args |
2015-07-23 00:27:42 | rhettinger | set | recipients:
+ rhettinger, vstinner, r.david.murray, eric.snow, serhiy.storchaka |
2015-07-23 00:27:42 | rhettinger | set | messageid: <1437611262.58.0.134158970428.issue24681@psf.upfronthosting.co.za> |
2015-07-23 00:27:42 | rhettinger | link | issue24681 messages |
2015-07-23 00:27:40 | rhettinger | create | |
|