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 patrila
Recipients patrila
Date 2017-01-04.13:50:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1483537854.64.0.339355431872.issue29153@psf.upfronthosting.co.za>
In-reply-to
Content
Dear Python developers

The tests

    test.test_asynchat.TestAsynchat.test_close_when_done
    test.test_asynchat.TestAsynchat_WitrhPoll.test_close_when_done

fail with

======================================================================
FAIL: test_close_when_done (test.test_asynchat.TestAsynchat)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../Lib/test/test_asynchat.py", line 256, in test_close_when_done
    self.assertGreater(len(s.buffer), 0)
AssertionError: 0 not greater than 0

======================================================================
FAIL: test_close_when_done (test.test_asynchat.TestAsynchat_WithPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../Lib/test/test_asynchat.py", line 256, in test_close_when_done
    self.assertGreater(len(s.buffer), 0)
AssertionError: 0 not greater than 0

Looking in the source code we see

        self.assertEqual(c.contents, [])
        # the server might have been able to send a byte or two back, but this
        # at least checks that it received something and didn't just fail
        # (which could still result in the client not having received anything)
        self.assertGreater(len(s.buffer), 0)

We therefore conjecture that the server was able to send all data back.
The relevant part is around line 61, the run() method of echo_server.

                # this may fail on some tests, such as test_close_when_done,
                # since the client closes the channel when it's done sending
                while self.buffer:
                    n = conn.send(self.buffer[:self.chunk_size])
                    time.sleep(0.001)
                    self.buffer = self.buffer[n:]


Indeed, if we change the sleeping time to something larger, e.g. 1sec. The tests pass fine.

In general it is a bad habit to relay on "hardware to be slow enough" to work/pass.
I therefore propose to introduce a separate field in echo_server which is set to True if the server has received some data.
Patch is attached and also included below. It is tested against Python-3.6.0 (sorry no "default" branch).
Python 3.5.3rc1 also works, but the patch below has an offset of -1 (the import warnings line was added/removed depending on the point of view).
For Python 2.7.13 the "same patch" also works but needs different line numbers and also different context. Patch is attached.

Patch for 3.6.0:

--- a/Lib/test/test_asynchat.py
+++ b/Lib/test/test_asynchat.py
@@ -42,12 +42,15 @@
             self.event.set()
             conn, client = self.sock.accept()
             self.buffer = b"" 
+            self.received_something = False
             # collect data until quit message is seen
             while SERVER_QUIT not in self.buffer:
                 data = conn.recv(1)
                 if not data:
                     break
                 self.buffer = self.buffer + data
+            if self.buffer:
+                self.received_something = True

             # remove the SERVER_QUIT message
             self.buffer = self.buffer.replace(SERVER_QUIT, b'')
@@ -252,7 +255,7 @@
         # the server might have been able to send a byte or two back, but this
         # at least checks that it received something and didn't just fail
         # (which could still result in the client not having received anything)
-        self.assertGreater(len(s.buffer), 0)
+        self.assertTrue(s.received_something)

     def test_push(self):
         # Issue #12523: push() should raise a TypeError if it doesn't get
History
Date User Action Args
2017-01-04 13:50:54patrilasetrecipients: + patrila
2017-01-04 13:50:54patrilasetmessageid: <1483537854.64.0.339355431872.issue29153@psf.upfronthosting.co.za>
2017-01-04 13:50:54patrilalinkissue29153 messages
2017-01-04 13:50:54patrilacreate