Steve Holden wrote:
> Thomas Wouters wrote:
>> I'm thinking that it could probably try to connect to a less reliable
>> website, but that's just moving the problem around (and possibly harassing
>> an unsuspecting website, particularly around release-time.) Perhaps the test
>> should try to connect to a known unconnecting site, like a firewalled port
>> on www.python.org? Not something that refuses connections, just something
>> that times out.
>>
> Couldn't the test use subprocess to start a reliably slow server on
> localhost? It might even be possible to retrieve the ephemeral port
> number used by the server, to avoid conflicts with already-used ports on
> the testing machine.
About 3 years ago I submitted the patch for test_timeout which had fixed some
of these issues:
http://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470
Now I think the patch need more review and need to be updated for the current
Python version and maybe some new ideas.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4