|Marked as misclassified
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] 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:
hup = signal.signal(signal.SIGHUP, self.trivial_signal_handler)
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.)
|2019-08-01 07:31:14||jeff.allen||set||messageid: <email@example.com>|
|2019-08-01 07:31:14||jeff.allen||link||issue2790 messages|