[Python-Dev] Retrieve an arbitrary element from asetwithoutremoving it

[Georg Brandl]

Chris Bergstresser schrieb:
> On Thu, Nov 5, 2009 at 11:43 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> I read Raymond's suggestion rather as a question: why bother with a
>> tedious, multi-year process, when a three-line function will achieve
>> exactly the same?
> 
>    Because it doesn't achieve exactly the same.  What I want is a
> sane, rational way to describe what I'm doing in the core API, so
> other programmers learning the language don't spend the amount of time
> I did perplexed that there was a .pop() and a .remove() and a
> .discard(), but there wasn't a .pick().  I don't want to have to write
> the same little helper function in every project to fill a deficiency
> in the library.

Why don't you write that little helper function only in those projects that
actually need it?  I suspect that will be a small fraction...

> I don't want to have to argue about the flaws in
> solutions with race conditions, or the fact that cheap functions
> become expensive functions when performed over the network, or that
> there's a real value in having an atomic operation which throws a sane
> exception when it fails, or how it's disturbing to my OCD core to have
> an API which believes:
> 
>   if x in s:
>     s.remove(x)
> 
> ... is too confusing, so there should be a .discard() method, but ...
> 
>   for x in s:
>     break
> 
> ... is self-evident and obvious, so there's no need for a .pick().

It's not just the self-evidence of the required "workaround" that determines
whether an API function is added to a builtin type.  It's whether you need it.
Imagine someone asking for a function on lists that removes duplicates, but
keeps the order of all first occurrences.  This is not a completely unimaginable
method, and writing it by hand is more than a few lines (see e.g.
http://code.activestate.com/recipes/52560/#c1).  Still, it's not needed
frequently enough to require being a list method.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.