From: A. Jesse Jiryu Davis <jesse@mongodb.com>
Date: Fri, 24 Apr 2015 13:32:34 +0000 (-0400)
Subject: More detail about porting from toro.Event.
X-Git-Tag: v4.2.0b1~10^2
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=85ff3a087045cae3845da714dbeb762350bdca90;p=thirdparty%2Ftornado.git

More detail about porting from toro.Event.
---

diff --git a/docs/releases/next.rst b/docs/releases/next.rst
index 821d8bd90..313006e61 100644
--- a/docs/releases/next.rst
+++ b/docs/releases/next.rst
@@ -46,9 +46,11 @@ Toro's ``Semaphore.wait`` allowed a coroutine to wait for the semaphore to
 be unlocked *without* acquiring it. This encouraged unorthodox patterns; in
 Tornado, just use `~.Semaphore.acquire`.
 
-Toro's ``Condition.wait`` raised a ``Timeout`` exception after a timeout. But in
-Tornado, the `.Future` returned by `.Condition.wait` resolves to False after a
-timeout::
+Toro's ``Event.wait`` raised a ``Timeout`` exception after a timeout. In
+Tornado, `.Event.wait` raises `tornado.gen.TimeoutError`.
+
+Toro's ``Condition.wait`` also raised ``Timeout``, but in Tornado, the `.Future`
+returned by `.Condition.wait` resolves to False after a timeout::
 
     @gen.coroutine
     def await_notification():
@@ -57,7 +59,6 @@ timeout::
         else:
             print('condition is true')
 
-
 In lock and queue methods, wherever Toro accepted ``deadline`` as a keyword
 argument, Tornado names the argument ``timeout`` instead.