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

Chris Rebert pyideas at rebertia.com
Fri Feb 13 08:00:16 CET 2009


On Thu, Feb 12, 2009 at 10:46 PM, Ralf W. Grosse-Kunstleve
<rwgk at yahoo.com> wrote:
>
>> It's true that the results you found aren't consistent with O(1),
>> but as I understand it, Python dicts are O(1) amortized ("on average
>> over the long term"). Sometimes dicts resize, which is not a constant
>> time operation, and sometimes the dict has to walk a short linked list,
>> which depends on the proportion of hashes that lead to a collisions.
>
> Thanks for the insight. I didn't know such a process is considered
> O(1). I agree it is fair because in practice it seems to work very
> well, but the "collisions" part can turn it into O(N) as demonstrated
> (in a crude way) by the script below. Therefore the O(1) classification
> is a bit misleading.
>
> My other script was simplified. I did look at more data points. The
> curve is amazingly flat but not a constant function.
>
> It is frustrating that simple requests like wanting a useful True or
> False, that costs nothing, instead of a useless None, tend to digress
> like this ...

It may seem like just a simple feature request, but by not allowing
it, we preserve the consistency, cleanness, and relative purity of
Python, and I wouldn't trade these aspects of Python for anything,
least of which a small feature request that would only yield an very
small gain if approved.

As The Zen says: "Special cases aren't special enough to break the rules."
You're asking for the "special case" of a mutating method of 'set' to
break the general "rule" that mutating methods normally return None;
it's simply not special /enough/ to justify breaking this very handy
(and imho, intuitive) rule of thumb; or at least that seems to be the
consensus.

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com



More information about the Python-ideas mailing list