It seems that even those originally asking for set retrieval have gone silent, so I guess this isn't going anywhere. However, for the benefit of future discussions (because I'm sure this question will be raised again), I'd like to answer a couple of points raised by Stephen. On Sat, 31 Oct 2009 01:42:46 pm Stephen J. Turnbull wrote:
> If folks prefer a different name, by all means suggest it. I like > the name suggested by Wikipedia, "pick".
"Pick" has a connotation of removal in many contexts: "Pick a card, any card".
And in just as many, there is no connotation of removal. "Pick a colour". For what it's worth, Forth and similar stack-based languages usually have a function "pick" equivalent to pop-without-removal. pick seems to be a standard term for this behaviour.
Like get, to me it has a flavor of "according to some criterion": "a band of picked men". I would expect a pick or get operation to take an optional predicate.
I think you are underestimating the power of context here. In practice, method names are interpreted in the context of the data being operated on. We don't get confused that ConfigParser.get() has a different signature to dict.get(), which is different again from Queue.get(). list.pop() takes an index; dict.pop() takes a key and an optional second argument; set.pop() takes no argument at all. Is anyone actually confused by this? If not, why would set.get() be more confusing? I think far too many people say "this is confusing" when what they really mean is "I don't like this".
The use case I have so far observed people to have in mind is a cast from an equivalence class to a representative member.
The difficulty is that we actually have two related, but different, behaviours, and sadly we've conflated the two of them by using the same name "get" for both. One behaviour is what Wikipedia calls pick: set.pick() -> return an arbitrary element from set without removing it This is not useful for the cast you describe. For that, you need a method that takes an argument. I'm going to call it "retrieve", to avoid the baggage of "get": set.retrieve(x) -> return the element from set equal to x In the first case, it seems self-evident to me that having "arbitrary" mean "the same element each time it is called" really would condemn pick() to be unused, but I don't care enough to argue. In the second case, the retrieval isn't arbitrary, so this is not a problem that needs solving.
> No. Since sets are unordered, there's no way to seek to a specific > element.
I think people will realize that in fact *these* sets are ordered and they will demand a seek function for various practical purposes.
We can iterate over dicts, and the order is arbitrary but consistent. Where are the people clamouring for dict.seek()? -- Steven D'Aprano