Issue2790

test_signal.BasicSignalTests.test_getsignal has been failing for a while, so I have looked into the reason why two values that look the same are not reported as equal:

     [exec] FAIL: test_getsignal (test.test_signal.BasicSignalTests)
     [exec] ----------------------------------------------------------------------
     [exec] Traceback (most recent call last):
     [exec]   File "/home/travis/build/jeff5/jython/dist/Lib/test/test_signal.py", line 216, in test_getsignal
     [exec]     self.assertEquals(signal.getsignal(signal.SIGHUP), hup)
     [exec] AssertionError: java.lang.Terminator$1@3ce1ca45 != java.lang.Terminator$1@3ce1ca45

The test that produces this runs:

    def test_getsignal(self):
        hup = signal.signal(signal.SIGHUP, self.trivial_signal_handler)
        self.assertEquals(signal.getsignal(signal.SIGHUP),
                          self.trivial_signal_handler)
        signal.signal(signal.SIGHUP, hup)
        self.assertEquals(signal.getsignal(signal.SIGHUP), hup)

and it is the second assertEquals that fails.

The objects in question are different Java objects, both Signal$SunMiscHandler, and proxied by a PyObjectDerived. __eq__ delegates to the proxied objects' comparison, which is Object.equals, and therefore we end up testing object identity. The second call to signal.signal, to re-install the original handler hup, creates a distinct Signal$SunMiscHandler, hence the problem. Its (private) fields are the same, so it has the intended effect, and its toString looks just like the original. But == still yields False.

I will skip this test for now, with a reference to this issue.

Our implementation of signal (see #1074) is somewhat incomplete, and a lot of test_signal is disabled anyway. The present issue is bounded to the __eq__ issue. A general overhaul of signal may be in order, but a point fix would do. (Not marking this for 2.7.2.)