Update next-release notes and document the asyncio module.

diff --git a/docs/asyncio.rst b/docs/asyncio.rst
new file mode 100644 (file)
index 0000000..8ec1ee1
--- /dev/null
+++ b/docs/asyncio.rst
@@ -0,0 +1,36 @@
+``tornado.platform.asyncio`` --- Bridge between ``asyncio`` and Tornado
+=======================================================================
+
+.. module:: tornado.platform.asyncio
+
+This module integrates Tornado with the ``asyncio`` module introduced
+in Python 3.4 (and available `as a separate download
+<https://pypi.python.org/pypi/asyncio>`_ for Python 3.3).  This makes
+it possible to combine the two libraries on the same event loop.
+
+Most applications should use `AsyncIOMainLoop` to run Tornado on the
+default ``asyncio`` event loop.  Applications that need to run event
+loops on multiple threads may use `AsyncIOLoop` to create multiple
+loops.
+
+.. py:class:: AsyncIOMainLoop
+
+    ``AsyncIOMainLoop`` creates an `.IOLoop` that corresponds to the
+    current ``asyncio`` event loop (i.e. the one returned by
+    ``asyncio.get_event_loop()``).  Recommended usage::
+
+        from tornado.platform.asyncio import AsyncIOMainLoop
+        import asyncio
+        AsyncIOMainLoop().install()
+        asyncio.get_event_loop.run_forever()
+
+.. py:class:: AsyncIOLoop
+
+    ``AsyncIOLoop`` is an `.IOLoop` that runs on an ``asyncio`` event loop.
+    This class follows the usual Tornado semantics for creating new
+    ``IOLoops``; these loops are not necessarily related to the
+    ``asyncio`` default event loop.  Recommended usage::
+
+        from tornado.ioloop import IOLoop
+        IOLoop.configure('tornado.platform.asyncio.AsyncIOLoop')
+        IOLoop.instance().start()

diff --git a/docs/integration.rst b/docs/integration.rst
index 6435912d92aa2dc3f6b5341fff2eadcb289a3ed6..cceeb6fbf2510b1d8d7ecb324b03e82da3d4b77b 100644 (file)
--- a/docs/integration.rst
+++ b/docs/integration.rst
@@ -4,6 +4,7 @@ Integration with other services
 .. toctree::
 
    auth
+   asyncio
    caresresolver
    twisted
    websocket

diff --git a/docs/releases/next.rst b/docs/releases/next.rst
index 0a4638ea332bad16c7599f9c43f517e497e16cee..5d7520b8624ad1e1f1aacb493b37bf3282d69d9c 100644 (file)
--- a/docs/releases/next.rst
+++ b/docs/releases/next.rst
@@ -69,4 +69,21 @@ In Progress
 * On Python 2.6, ``simple_httpclient`` now uses TLSv1 instead of SSLv3.
 * Added `.GoogleOAuth2Mixin` support authentication to Google services
   with OAuth 2 instead of OpenID and OAuth 1.
-* TODO: document asyncio and C extension module.
+* `.Application` now accepts 4-tuples to specify the ``name`` parameter
+  (which previously required constructing a `.URLSpec` object instead of
+  a tuple).
+* ``simple_httpclient`` now enforces the connect timeout during DNS resolution.
+* Tornado now depends on the `backports.ssl_match_hostname
+  <https://pypi.python.org/pypi/backports.ssl_match_hostname>`_ when
+  running on Python 2.  This will be installed automatically when using ``pip``
+  or ``easy_install``
+* Tornado now includes an optional C extension module, which greatly improves
+  performance of websockets.  This extension will be built automatically
+  if a C compiler is found at install time.
+* The `tornado.platform.asyncio` module provides integration with the
+  ``asyncio`` module introduced in Python 3.4.
+* Malformed ``x-www-form-urlencoded`` request bodies will now log a warning
+  and continue instead of causing the request to fail (similar to the existing
+  handling of malformed ``multipart/form-data`` bodies.  This is done mainly
+  because some libraries send this content type by default even when the data
+  is not form-encoded.

diff --git a/tornado/web.py b/tornado/web.py
index e6598bb04c4f56b1441895369356f9f4249d2ebe..b6d7e97edd941b9cf4c2c5826c96f8d562eaf6f7 100644 (file)
--- a/tornado/web.py
+++ b/tornado/web.py
@@ -1448,10 +1448,16 @@ class Application(object):
     or (regexp, request_class) tuples. When we receive requests, we
     iterate over the list in order and instantiate an instance of the
     first request class whose regexp matches the request path.
+    The request class can be specified as either a class object or a
+    (fully-qualified) name.
 
-    Each tuple can contain an optional third element, which should be
-    a dictionary if it is present. That dictionary is passed as
-    keyword arguments to the contructor of the handler. This pattern
+    Each tuple can contain additional elements, which correspond to the
+    arguments to the `URLSpec` constructor.  (Prior to Tornado 3.2, this
+    only tuples of two or three elements were allowed).
+
+    A dictionary may be passed as the third element of the tuple,
+    which will be used as keyword arguments to the handler's
+    constructor and `~RequestHandler.initialize` method.  This pattern
     is used for the `StaticFileHandler` in this example (note that a
     `StaticFileHandler` can be installed automatically with the
     static_path setting described below)::
@@ -1474,6 +1480,7 @@ class Application(object):
     and ``/robots.txt`` from the same directory.  A custom subclass of
     `StaticFileHandler` can be specified with the
     ``static_handler_class`` setting.
+
     """
     def __init__(self, handlers=None, default_host="", transforms=None,
                  wsgi=False, **settings):