On Tue, Oct 27, 2009 at 12:47 PM, Raymond Hettinger <pyt...@rcn.com> wrote:
> [Chris Bergstresser]
> Still, I think my
>>
>> point stands--it's a clear extrapolation from the existing dict.get().
>
> Not really. One looks-up a key and supplies a default value if not found.
> The other, set.get(), doesn't have a key to lookup.
Right, which is why dict.get() takes a key as an argument, while
the proposed set.get() wouldn't.
> A dict.get() can be meaningfully used in a loop (because the key can vary).
> A set.get() returns the same value over and over again (because there is no
> key).
I don't think "can it be used meaningfully in a loop?" is an
especially interesting or useful way of evaluating language features.
Besides, why would set.get() necessarily return the same value
over and over again? I thought it would be defined to return an
arbitrary value--which could be the same value over and over again,
but could just as easily be defined to return a round-robin value, or
the minimum value, or some *other* value as the container defined it.
The fact is, set.get() succinctly describes an action which is
otherwise obscure in Python. It doesn't come up all that frequently,
but when it does the alternatives are poor at best. Add in the
uncertainty about which is optimized (imagine the situation where the
set you're calling is actually a proxy for an object across the
network, and constructing an iterator is expensive) and you start to
see the value.
-- Chris
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
