Changeset 2c9a2b588a89 broke the pretty-printing of sets by the gdb plugin.
Here is a temptative patch. It works, but I don't know enough to know whether that's the right coding style for a gdb plugin. Dave?

See also the python-dev thread about other drawbacks of the new dummy approach: http://mail.python.org/pipermail/python-dev/2013-August/128025.html

Raymond, if you don't have time for this issue, I'd prefer your patch to be reverted. It hasn't been proven to accelerate any benchmark, and the problems it triggered need solving.

Antoine's patch looks reasonable to me, FWIW.

This is a bummer.  The internal comments made the claim that any python object would suffice.   The use of a unicode object was unfortunate because it isn't guaranteed to be unique (i.e. a user can legitimately store "<dummy>" as a valid member of a set).  As a consequence, the tight loops for the hash table lookups had to add special case checks for the dummy variables.  Eliminating those checks made the generated code shorter and faster.  It also paved the way for a future optimization for non-debug builds to eliminate all non-essential increfs and decrefs to the dummy object.

In other words, we're paying a price for the dummy object being printable as a string.

Antoine, thanks to the link to the python-dev discussion.  I hope we can come with a solution that doesn't involve going back to unicode objects.

> In other words, we're paying a price for the dummy object being
> printable as a string.

Which is pointless, I agree.

> Antoine, thanks to the link to the python-dev discussion.  I hope we
> can come with a solution that doesn't involve going back to unicode
> objects.

Re-using PyDict's dummy object would be a solution, AFAICT?

New changeset be29efa60b68 by Raymond Hettinger in branch 'default':
Issue 18772:  Restore set dummy object back to unicode and restore the identity checks in lookkey().
http://hg.python.org/cpython/rev/be29efa60b68

Antoine, can you please verify the gdb plug-in is working again?

> Antoine, can you please verify the gdb plug-in is working again?

test_gdb works fine here, yes.

Thank you.

I just applied the dict version of dummy to sets in http://hg.python.org/cpython/rev/f0202c3daa7a
and it unexpectedly broke test_gdb again:

FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_gdb.py", line 319, in test_sets
    self.assertEqual(gdb_repr, "{'b'}")
AssertionError: "{<<dummy key> type at remote 0x103b35c0>, 'b'}" != "{'b'}"
- {<<dummy key> type at remote 0x103b35c0>, 'b'}
+ {'b'}



Antoine, can you see what the issue is?  Why does this show as the dummy key type instead of being recognized as the object returned by _PySet_Dummy?   I'm not sure why this works for dicts, but not for sets.

Checking for dummies in dicts in python-gdb.py is implicit (see PyDictObjectPtr.iteritems()): entries whose value is NULL are not printed.

Set entries do not have values, so instead pySetObjectPtr.write_repr() uses a hack with the repr() of the key to check for dummies. Instead I think we should re-use the approach in my patch: publish the dummy object as a (private) C API so that python-gdb.py can simply compare the key pointer by equality.

Attaching a patch, but I don't have a way to test it.

Checking repr() perpetuates the original hack so, why it may work, I think it's better if we take the opportunity to solve it cleanly.
I'll try to take a look tonight (I suppose you're under Windows?).

Attached patch solves the issue and removes the repr()-based hack in the gdb plugin.

Since nobody seems to object to the patch, I'm commit it :)

New changeset 2f1bac39565a by Antoine Pitrou in branch 'default':
Issue #18772: fix the gdb plugin after the set implementation changes
http://hg.python.org/cpython/rev/2f1bac39565a

Well, it should be ok now (at least now the test passes here).