On 10/11/05, Tim Peters <[EMAIL PROTECTED]> wrote: > Guido understands use cases for blocking and non-blocking put/get, and > Queue always supported those possibilities. The timeout argument got > added later, and it's not really clear _why_ it was added. timeout=0 > isn't a sane use case (because the same effect can be gotten with > non-blocking put/get).
In the socket world, a similar bifurcation of the API has happened (also under my supervision, even though the idea and prototype code were contributed by others). The API there is very different because the blocking or timeout is an attribute of the socket, not passed in to every call. But one lesson we can learn from sockets (or perhaps the reason why people kept asking for timeout=0 to be "fixed" :) is that timeout=0 is just a different way to spell blocking=False. The socket module makes sure that the socket ends up in exactly the same state no matter which API is used; and in fact the setblocking() API is redundant. -- --Guido van Rossum (home page: http://www.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/archive%40mail-archive.com
