[Michael Hudson]
... If noone beats me to it, I'll post a better fix to sf next week, complete with test-cases and suitably "encouraging" comments.
Ah, no need -- looks like I was doing that while you were writing this. Checked in already. So long as we're happy to settle for senseless results that simply don't blow up, the only other trick you really needed was to save away the value in a local vrbl and incref it across the key->string bit; then you don't have to worry about key->string deleting the value, or about the table entry it lived in going away (because you get the value from the (still-incref'ed) *local* vrbl later, not from the table again).
I can't easily see other examples of the problem; there certainly might be things you could do with comparisons that could trigger crashes, but that code's so hairy that it's almost impossible for me to be sure.
It's easy to be sure: any code that tries to remember anything about a dict (ditto any mutable object) across a "dangerous" call, other than the mere address of the object, is a place you *can* provoke a core dump. It may not be easy to provoke, and a given provoking test case may not fail across all platforms, or even every time you run it on a single platform, but it's "an obvious" hole all the same.