[Python-ideas] set.add() return value

Raymond Hettinger python at rcn.com
Tue Feb 17 03:13:25 CET 2009


[Steven D'Aprano]
> What's the use-case for this? What's wrong with doing this?
> 
> if 42 in myset:
>     myset.add(42)
> 
> Short, sweet, and doesn't require any new methods.

I think you meant:  "if 42 not in myset".

Am -1 on the proposed change.  

AFAICT, it will never save more than one line of code.
The current version is explicit and clear.
Moreover, it does not require special knowledge to read.

Currently, the set API has a zero learning curve and doesn't
demand that you remember a rule particular to Python.
In contrast, the proposed version requires that you know
that Python has a special API and you need to remember that
when you're reading someone else's code.

Give this snippet to five Python programmers (not in this thread)
and see if they correctly deduce when f(x), f(y), f(z), and f(m) will
be called.  Also, see if they can correctly assert known post-conditions
(after each if-statement and before each function call).

    if(not myset.add(x)):
          f(x)
    else:
          g(x)
    if(myset.discard(y)):
          f(y)
    else:
          g(y)
    if(myset.update(z):
          f(z)
    else:
          g(z)
    if(myset):
          f(m)
    else:
          g(m)

As I mentioned in another post, this API is counterintuitive for
anyone who is used to other languages where operations like
set.add() always returns self and lets them write code like:

      myset.add(x).add(y).add(z)

Essentially the argument against boils down to there not being
an intuitively obvious correct interpretation of what the code
does while the existing approach is crystal clear.

The set API currently has no rough edges.  It is one of the cleanest
APIs in the language and I hope it stays that way.



Raymond







More information about the Python-ideas mailing list