Logged In: YES 
user_id=133955

Hi again,

> Antoine, yes a pop()/add() combination is efficient.

Ok, thanks.

>  IMO,
> it also clear in intent, easy to write, flexible enough for
> a variety of applications, the pop() is atomic, 

Small correction: the pop() is atomic, but the pop/add
sequence is not, AFAIU ;)

> Question for Antoine:  Have you ever had this need with
> other containers?

I think I had it for a dict sometime. For lists and tuples,
you can just use my_container[0] of course.
But sets are often used differently than dicts IMHO. Dicts
are mappings: you give a precise key and get the exact value
associated with it. Sets are bags: sometimes you just want
to pick an item, as you would do in a real bag, without
looking inside to choose a specific item.

> Since choose() would not be a
> mutating method, it would also apply to frozensets.  Does it
> have any use there?  Any appearance in a loop would be farce
> since it would always return the same value (the frozenset
> never mutates).

The variable to which you apply the method call could
reference another frozenset on the next loop iteration...
Yes, it doesn't sound very frequent.

> Question for everyone:  Is there any known application for
> choose() that isn't met by pop()/add() irrespective of
> whether it "feels right"?

I don't think so indeed. (it would be the case if the API
guaranteed atomicity in the case of single bultin method
calls like choose())

> For applications other than Michael's, we won't know the
> size of the set in advance.  Are there any examples of using
> choose() that won't have to have ugly EAFP or LBYL code to
> handle the case where the set is empty?

First, sometimes you know the set is non-empty without
knowing its size in advance (for example you are inside a
big block beginning with "if len(my_set)"). Second, error
catching is still needed with other alternatives (you either
have to catch KeyError when doing s.pop(), or StopIteration
when doing iter(s).next()).

> Rather than a method just for sets, is it a more appropriate
> solution to have a generic function that takes any iterable
> and returns its first element:

Well, I thought global builtin functions were less favoured
than methods. But this doesn't sound stupid. On the other
hand, generic functions are less easy to find about (usually
if I want to have the set API, I type help(set) in a Python
shell which I always have open. But there is no quick way to
have a list of the builtin functions that can apply to
iterables (*)). In my experience, I often forget about the
generic builtin functions that come with Python - maybe
that's just me.

(*) if there was a base type "iterable" with the generic
method first() defined on it, as well as some of the other
functions defined in the itertools module, it would probably
be more elegant and more frequently used.


Anyway, if the concern with builtin types is to avoid
bloating the API, then I admit that it's a fair concern and
that the motivation to add the choose() method might indeed
not be convincing enough.