Final (final?) update to patch about socket timeout...
...in socket.py and httplib.py, with tests and docs. The patch is #1676823. Basically what I did now is: - Just put a timeout default to None. If None, skip settimeout() call. - Copy the exceptions behaviour that we have actually in the higher level libraries, to be sure we aren't breaking anything. - The function is now public, named "create_connection". Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Looks good. I forget -- can you check this in yourself? If so, do it! If not, let me know and I'll do it for you. Thanks for doing this! --Guido On 3/23/07, Facundo Batista <facundo@taniquetil.com.ar> wrote:
...in socket.py and httplib.py, with tests and docs.
The patch is #1676823.
Basically what I did now is:
- Just put a timeout default to None. If None, skip settimeout() call.
- Copy the exceptions behaviour that we have actually in the higher level libraries, to be sure we aren't breaking anything.
- The function is now public, named "create_connection".
Regards,
-- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Looks good. I forget -- can you check this in yourself? If so, do it! If not, let me know and I'll do it for you. Thanks for doing this!
Done. You're welcome. I'll start now with the patch about the *other* higher level libraries, :) Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
On 3/23/07, Facundo Batista <facundo@taniquetil.com.ar> wrote:
Guido van Rossum wrote:
Looks good. I forget -- can you check this in yourself? If so, do it! If not, let me know and I'll do it for you. Thanks for doing this!
Done. You're welcome.
I'll start now with the patch about the *other* higher level libraries, :)
Great -- those should be very easy. If you feel confident you don't have to get them reviewed before you check in. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Facundo Batista wrote:
Guido van Rossum wrote:
Looks good. I forget -- can you check this in yourself? If so, do it! If not, let me know and I'll do it for you. Thanks for doing this!
Done. You're welcome.
Tests failed because of this commit *only* in "alpha Tru64 5.1 trunk" buildbot. The test that failed is one that does: sock = socket.create_connection((HOST, PORT), timeout=10) self.assertEqual(sock.gettimeout(), 10) And failed with timeout, obviously because it couldn't connect to itself in 10 seconds. The "connect to itself" part is implemented in the very same way (i.e. copied) that in the rest of the tests, even using the same port and everything. Note that the previous regression test, in this machine, also failed in test_socket, *before* my commit. My questions are: could this machine be so loaded that it couldn't connect in 10 seconds? Or something is happening in this machine/architecture? Shall I try to increment the timeout to 60, in these tests (where actually the timeout can be anything) to see what happens? Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
Tests failed because of this commit *only* in "alpha Tru64 5.1 trunk" buildbot.
Also it fails in "g4 osx.4 trunk". In all the other platforms it works ok.
The test that failed is one that does:
sock = socket.create_connection((HOST, PORT), timeout=10) self.assertEqual(sock.gettimeout(), 10)
Which is very strange, because this is the third test in "testTimeoutAttribute" (this method actually tries different ways of calling the function, no real functionality). In other tests, sometimes fail in the second test of the method. In the test setUp() method, I'm setting the serving socket up, with a listen(1). I can try to to put a listen(5). I can try to reorder the tests. I can try a lot of things to see why there's a problem here. But I do not have access to any of both architectures (Alpha and G4). And I don't want to try everything through commits in the repository (or should I?). I do not want to leave these failing tests. I'll fix them, or comment them out (actually, the tests are very superficial). What do you do in these cases? How do you deal with failing test cases in platforms to which you do not have access? Thanks! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Facundo Batista wrote:
Tests failed because of this commit *only* in "alpha Tru64 5.1 trunk" buildbot.
Also it fails in "g4 osx.4 trunk". In all the other platforms it works ok.
As usual, human error. Now I used the already present threading custom testing architecture in test_socket.py, and fixed an issue in httplib.py, and everything is ok. Well, not a big ok, some buildbots fails because other causes, and even the "alpha Tru64" fails in test_socket, but it was failing *before * my check ins, so I'm sure I didn't break anything. This process is finished. I'll continue to work in the other libraries. Sorry for the mess. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
participants (2)
-
Facundo Batista -
Guido van Rossum