On Tue, Oct 27, 2009 at 12:47 PM, Raymond Hettinger email@example.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.