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

[Guido van Rossum]

On Thu, Feb 19, 2009 at 1:01 AM, Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
>> All in all, I am now siding with Raymond -- let's leave well enough
>> alone. Hopefully we can now retire this thread, I don't think there's
>> much more that can be said that hasn't been said already.
>
> FWIW, a few thoughts anyway:
>
> - I don't actually care about performance**. It was a mistake on my part to try to abuse
>  the performance argument for what I was really after: elegance (defined as power/volume
>  while still looking simple).
>
> - I always assumed it must be an oversight that set.add() doesn't return a trivial
>  piece of information that it has. Somebody has made the arbitrary decision to withhold
>  this information from me, like you withhold certain information from a child. It feels
>  very wrong. I'm grown up and wish to take responsibility myself. "If I don't like it,
>  you cannot use it" is forceful; "If you don't like it, just don't use it" is a much
>  better tone between partners.
>
> - The purity argument was used a lot. In my opinion, set would be pure if it didn't arbitrarily
>  withhold information from me that would allow me to make my algorithms more concise. Or as
>  Einstein put it, "Make everything as simple as possible, but not simpler."
>  set.add() returning None is failing the "but" part.

I'm sorry, but your choice of words in the last two bullets feels very
condescending to me, and despite my vow to end the thread I cannot let
it the last words spoken be the words of a sore loser.

Your position completely ignores the argument about people getting
confused about what the return value would mean: "it was added" vs.
"it was already there". It also seems to counter the elegance
argument: if we cram as much information into every API as we can,
certainly our APIs will feel more crowded and less elegant. Why not
have list.append() return the new length of the list? Etc., etc.

The overarching design principle in Python is to encourage the most
maintainable code. This usually means to encourage concise code, but
not so concise as to be hard to understand (or easily to misread) for
the next person maintaining it.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)