On Thu, Nov 5, 2009 at 11:43 PM, "Martin v. Löwis" <[email protected]> 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. 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().
-- Chris
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
