Sometimes, a non-removing pop() is needed. In current Python versions,
it can achieved by one of the following ways:

1. 
x = some_set.pop()
some_set.add(x)

2. 
for x in some_set: 
        break

3.
x = iter(some_set).next()

More native and clean would, however, be 
some_set.get()

The attached patch does this for set(). If this is accepted by the
community, frozenset should be extended as well.

Without tests, this patch is unacceptable.

added tests for get() to test_set.py

Any reason you don't want to call set_next from set_get?

I would say

static PyObject *
set_get(PySetObject *so)
{
	register Py_ssize_t pos = 0;
	register setentry *entry;
        if (set_next(so, &pos, &entry)) {
              Py_INCREF(entry->key);
              return entry->key;
        }
        /* set appropriate error */
        return NULL;
}

BTW, what your patch is supposed to do on set().get()?
}

No particular reason, besides that it is ripped off of pop().

Your solution (omitting "register") gives the same performance. Looks
cleaner, of course.

The patch tries to provide a clean way of "for x in some_set: break", as
explained above. See the recent python-dev mailing list musings.

After a long discussion on python-dev, this proposal is rejected in
favor of adding documentation notes on the ways to non-destructively
retrieve an arbitrary item from a set or frozenset.

Here is an except from the end of the thread:

[Steven D'Aprano]
>> Anyway, given the level of opposition to the suggestion, I'm no longer
>> willing to carry the flag for it. If anyone else -- perhaps the OP --
>> feels they want to take it any further, be my guest.

[geremy condra]
> I've said before that I'd like there to be one, standard way of
> doing this. A function call- set.pick() seems reasonably named
> to me- is probably the cleanest way to do that. Absent that,
> an example in the docs that illustrates the preferred idiom
> would be great. 

[Raymond]
Summarizing my opposition to a new set method:
1) there already are at least two succinct ways to get the same effect
2) those ways work with any container, not just sets
3) set implementations in other languages show that this isn't needed.
4) there is value to keeping the API compact
5) isn't needed for optimization (selecting the same value in a loop
makes no sense)
6) absence of real-world code examples that would be meaningfully improved

[Terry Reedy]
Agreed

[Raymond]
I would be happy to add an example to the docs so that this thread
can finally end.

[Eric Smith]
Please do!

[Terry Reedy]
Yes!
'''


Leaving this open until I've done the documentation patch.

I don't want to pollute python-dev with more hopeless ideas, but I wonder 
if itertools could grow an efficient C-implemented

def first(collection):
   return next(iter(collection))

On the other hand, it probably belongs to recipes more than stdlib.  This 
is not really an iterator tool after all.