[Python-ideas] get method for sets?

[Mike Meyer]

On Wed, 16 May 2012 01:08:09 -0700
Bruce Leban <bruce at leapyear.org> wrote:
> On Wed, May 16, 2012 at 12:40 AM, Mike Meyer <mwm at mired.org> wrote:
> > On Wed, 16 May 2012 00:02:31 -0700
> > Bruce Leban <bruce at leapyear.org> wrote:

> > > Here's one definition of get:
> > > def get_from_set1(s):
> > >     """Return an arbitrary member of a set."""
> > >     return min(s, key=hash)
> >
> > >From poking around, at least at one time the fastest implementation
> > was the very confusing:
> >
> > def get_from_set(s):
> >    for x in s:
> >        return x
> I didn't claim it was fast. I actually wrote that version instead of the
> in/return version for a very specific reason: it always returns the same
> element. (The for/in/return version might return the same element every
> time too but it's not guaranteed.)

I didn't ask for a get that would always return the same element.

> > Basically, anytime you want to examine an arbitrary element of a set,
> > and would use pop, except you need to preserve the set for future
> > use. In my case, I'm running a series of tests on the set, and some
> > tests need an element.
> That's bordering on tautological. It's useful anytime you need it.

What do you expect? We've got a container type that has no way to
examine an element without modifying the container or wrapping it in
an object of a different another type. The general use case is that
you don't need the facilities of the wrapping type (except for their
ability to provide a single element) and you don't want to modify the
container.

Would you also complain that having int accept a string value in lieu
of using eval on untrusted input is a case of "it's useful anytime you
need it."?

> I don't think your test is very good if it uses the get I wrote
> above. Your test will only operate on one element of the set and
> it's easy to write functions which succeed for some elements of the
> set and fail for others.  I'd like to see an actual test that you
> think needs this that would not be improved by iterating over the
> list.

Talk about tautologies! Of course you can write tests that will fail
in some cases. You can also write tests that won't fail for your
cases. Especially if you know something about the set beforehand.

For instance, I happen to know I have a set of ElementTree elements
that all have the same tag. I want to check the tag.

One of the test cases starts by checking to see if the set is a
singleton. Do you really propose something like:

    if len(s) == 1:
	for i in s:
	    res = process(i)

or:

    if len(s) == 1:
	res = process(list(s)[0])

Or, as suggested elsewhere:

    if len(s) == 1:
	res = process(next(iter(s)))

Or, just to be really obtuse:

    if len(s) == 1:
        res = process(set(s).pop())

All of these require creating an intermediate object for the sole
purpose of getting an item out of the container without destroying the
container. This leads the reader to wonder why it was created, which
clashes with pretty much everything else in python. The only really
palatable version is sufficiently obscure that nobody else who needed
this API found it, or had it suggested to them by those responding to
their question.

> > Again, looking for a reason for this not existing turned up other
> > cases where people were wondering how to do this.
> Things are added to APIs and libraries because they are useful, not because
> people wonder why they aren't there. set.get as you propose is not
> sufficiently analogous to dict.get or list.__getitem__.

People wonder why an API is not there because they need it and can't
find it. I have a use for this API, so clearly it's useful. When I
didn't find it, I figured there might be a reason for it not existing,
so I asked the google djinn. Rather than providing a reason (djinn
being noticeably untrustworthy), it turned up other people who had the
same need as I did. I then asked this list the same question. Instead
of getting an answer to that question, I get a bunch of claims that "I
don't really need that", making me wonder if I've invoked another
djinn.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org