Fyi: http://bugs.python.org/issue14307
-----Original Message----- From: python-dev-bounces+kristjan=ccpgames....@python.org [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of Kristján Valur Jónsson Sent: 14. mars 2012 12:36 To: Guido van Rossum Cc: Antoine Pitrou; python-dev@python.org Subject: Re: [Python-Dev] SocketServer issues Yes, setting a timeout and leaving it that way is not the same. But setting the timeout for _accept only_ is the "same" except one approach requires the check of a bool return, the other the handling of a socket.timeout exeption. My point is, if sockets already have nice and well defined timeout semantics, why not use them, or even improve them (perhaps with an optional timeout parameter to the accept call) rather than reimplement them with an explicit select.select() call? Anyway, I'll take another look at the problem and possibly submit a patch suggestion. Thanks. K -----Original Message----- From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf Of Guido van Rossum Sent: 14. mars 2012 11:44 To: Kristján Valur Jónsson Cc: Antoine Pitrou; python-dev@python.org Subject: Re: [Python-Dev] SocketServer issues 2012/3/14 Kristján Valur Jónsson <krist...@ccpgames.com>: > Maybe this is all just nonsense, still it seems odd to jump through extra > hoops to emulate a functionality that is already supported by the socket > spec, and can be done in the most appropriate way for each implementation. I thought I had already explained why setting the timeout on the socket is not the same. -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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/kristjan%40ccpgames.com _______________________________________________ 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/archive%40mail-archive.com