Raymond Hettinger added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24681> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
