This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients Rhamphoryncus, christian.heimes, gvanrossum
Date 2007-11-29.18:19:32
SpamBayes Score 0.0075820684
Marked as misclassified No
Message-id <1196360373.38.0.711630190602.issue1517@psf.upfronthosting.co.za>
In-reply-to
Content
I can reproduce the segfault in 2.2 through 2.4; in 2.5 and 2.6 the
output is this instead:

Test 1, using __eq__(a, b).__nonzero__()
this is never the right answer
*****
Test 2, using tuple's tp_richcompare
New Watch 0xf7f8cbac
New Watch 0xf7f8cc0c
Deleting Watch 0xf7f8cbac
Deleting Watch 0xf7f8cbac
Deleting Watch 0xf7f8cc0c
Traceback (most recent call last):
  File "/tmp/db3.py", line 72, in <module>
    print(d[(Bar(), Watch())])
TypeError: __eq__() takes exactly 1 argument (2 given)

which suggests it's still there ("this is never the right answer").

In 3.0 the output from the 1st test is "this is an acceptable answer"
suggesting it's no longer there; but I suspect it's there in 3.0 as well
but due to the unicode transition the dict code there is different
enough that the example doesn't trigger it.

The key that needs to be INCREF'ed is actually startkey.  Patch attached.
Files
File name Uploaded
fix1517.diff gvanrossum, 2007-11-29.18:19:32
History
Date User Action Args
2007-11-29 18:19:33gvanrossumsetspambayes_score: 0.00758207 -> 0.0075820684
recipients: + gvanrossum, Rhamphoryncus, christian.heimes
2007-11-29 18:19:33gvanrossumsetspambayes_score: 0.00758207 -> 0.00758207
messageid: <1196360373.38.0.711630190602.issue1517@psf.upfronthosting.co.za>
2007-11-29 18:19:33gvanrossumlinkissue1517 messages
2007-11-29 18:19:32gvanrossumcreate