Hi Ben
You've definitely got a point. When you do
seen.add(key)
it's sometimes important to know if this changes 'seen'.
Here's a one-liner that does what you want:
key in seen or seen.add(key)
It's a bit obscure, and perhaps a bit too much
https://en.wikipedia.org/wiki/Code_golf. So here's a worked example.
>>> seen = set()
>>> 0 in seen or seen.add(0)
>>> 0 in seen or seen.add(0)
True
The first time '0 in seen' is False, so the OR part 'seen.add(0)' is
executed. As you and others have said, seen.add(key) always return None.
(The REPL does not echo the expression value if it is None.)
The second time '0 in seen' is True, so the OR part is not done, and the
value of the expression is True.
If you want, in your own code you can subclass set to provide the behaviour
you think is missing. Or just write a utility function. I think that would
in practice be better.
>>> def in_or_add(s, key):
... return key in s or s.add(key) or False
>>> seen = set()
>>> in_or_add(seen, 0)
False
>>> in_or_add(seen, 0)
True
An aside. Your proposal is:
> value. set.add would return True if the item was already in the set prior
> to insertion, and False otherwise.
This allows you to simplify your code example. But I find the semantics a
bit odd. If set.add(key) were to return a boolean, I'd expect it to be True
if the item genuinely was added. But your semantics are the other way
around.
My proposal of in_or_add and your revision of set.add both have the same
semantics. I think that is clear. But they have different names. If enough
people use a utility function such as in_or_add(s, key), then that makes a
good case for adding it as a set method.
Two final points. While processing the 'not key in seen' branch, an
exception might occur. Sometimes it's better to add the key to 'seen' once
all the associated processing is complete. (An exception that leaves the
system in an inconsistent state can cause problems later.) The second point
is that I'm not confident about 'in_or_add' as a name for the method.
Once again, thank you for your interesting idea.
--
Jonathan
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/AIZUO34NMWKH5GRZSVQ4BNF66OILU5VI/
Code of Conduct: http://python.org/psf/codeofconduct/
