More detail about porting from toro.Event.

diff --git a/docs/releases/next.rst b/docs/releases/next.rst
index 821d8bd90b364c8076a6a941a2a162ea259afa55..313006e614460241f76b4bf8cd4ab6b9a750da3f 100644 (file)
--- 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.