My point was only that, as far as I know, all the methods for built in container types that serve only to change what is contained return None, and that this was an intentional design choice, so changing it in one case would have to evoke a larger discussion about what those sorts of methods should return.

I wouldn't be opposed to that discussion happening and for any changes that are made to happen within 3.x because I doubt that very much code that currently exists depends on these methods returning None or even use what they return at all.

On Thu, Jun 25, 2020, 10:28 AM Ben Avrahami <> wrote:
Hey all,
Often I've found this kind of code:

seen = set()
for i in iterable:
  if i in seen:
    ...  # do something in case of duplicates
    ... # do something in case of first visit

This kind of code appears whenever one needs to check for duplicates in case of a user-submitted iterable, or when we loop over a recursive iteration that may involve cycles (graph search or the like). This code could be improved if one could ensure an item is in the set, and get whether it was there before in one operation. This may seem overly specific, but dicts do do this:

seen = {}
for i in iterable:
  if seen.set_default(i, some_value) is not None:
    ...  # do something in case of duplicates
    ... # do something in case of first visit

I think the set type would benefit greatly from its add method having a return value. set.add would return True if the item was already in the set prior to insertion, and False otherwise.

Looking at the Cpython code, the set_add_entry already detects existing entries, adding a return value would require no additional complexity.

Any thoughts?
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: