[Python-Dev] Retrieve an arbitrary element from a setwithoutremoving it
steve at pearwood.info
Sun Nov 1 12:21:15 CET 2009
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
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
> 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()?
More information about the Python-Dev