[Python-Dev] Retrieve an arbitrary element from a set without removing it

[Steven D'Aprano]

On Sat, 24 Oct 2009 02:02:48 pm Ben Finney wrote:
> Steven D'Aprano <steve at pearwood.info> writes:
> > On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
> > > Steven D'Aprano <steve at pearwood.info> writes:
> > > > The lack of get() in sets and frozensets is sounding more and
> > > > more to me like the victory of purity over practicality.
> > >
> > > What would be the input to ‘set.get’?
> >
> > It wouldn't take any input.
>
> That is even less obvious. I would expect a parameter-less ‘set.get’
> to get the set. Not terribly useful, but the name and function
> signature doesn't suggest anything else.

You already have the set. Why would you need a method that you call that 
returns the set you already have?

A method called "get" obviously gets something, and if it takes no 
arguments the only thing is has access to is the set. The obvious 
things it could get are the set as a whole or some part of the set. 
Since getting the set as a whole would be pointless, and we're allowed 
to assume that the language designers aren't lunatics who would waste 
time creating pointless methods, the obvious answer is that it gets 
some part of the set.

Since there's no obvious reason to choose one subset over another 
subset, the only useful thing it could return is a single arbitrary 
item. But if you're not willing to guess what it gets, you are 
permitted to read the docstring.


> > "get" is such a generic term that I don't believe that is a
> > problem.
>
> The problem above is made less problematic by the fact that the
> function signature (e.g. ‘foo_dict.get(key)’) clarifies the answer to
> the question “get what?”. Whereas ‘foo_set.get()’ doesn't communicate
> much at all to the reader.

You are demanding a level of intuitiveness that few, if any, functions 
in the standard library would be able to meet. Consider list.index(x): 
would you expect it to return the value at index x, or the index of 
value x? Either description is compatible with the name, and in fact 
people sometimes mix them up.

Or sorted() -- from the name alone, I'd expect this to work, but it 
doesn't:

>>> sorted(1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable


That's not a problem with the built-in function. I took a guess about 
the API, and guessed wrong. I'll learn from this, and get it right next 
time.


> If we want a method that gets one item from a set, perhaps the name
> can make it clearer: name it ‘set.getitem’. But which item should it
> get? The ‘__getitem__’ special method of lists and dictionaries
> requires an index or key as parameter.

Neither of which is appropriate for sets -- sets are unordered, so 
elements don't have indexes, and they don't map keys to values. They 
just have elements.

Sets are not lists, and they're not dicts. Analogies only go so far, and 
you can't reason about set methods by considering how lists or dicts 
will behave.



-- 
Steven D'Aprano