Files changed (1)
This document only describes new features in CherryPy 3.2. A detailed "How To Upgrade" document is at [wiki:UpgradeTo32 UpgradeTo32].
+!CherryPy 3.2 runs on Python 3! You'll find separate downloadable packages, as well as a separate Subversion branch.
+The FastCGI support in `cherryd` is much improved and tested, including socket file support; also, autoreload and the conflicting signal handlers are now off by default. SCGI support is also included via the `-s` option to `cherryd` (thanks georgem).
+`cherryd` now also adds the current directory to sys.path, so that modules in it can be more easily imported.
+Open sockets are no longer inherited by child processes (thanks nicolas grilly). See #856 for more details.
+To find a handler for the current request, !CherryPy's default dispatcher traverses a tree of objects and methods. Beginning in CherryPy 3.2, when a controller possesses a `_cp_dispatch(vpath)` method, !CherryPy's default dispatcher will now use its return value as the 'next hop' in the object traversal. Returning `None` effectively stops traversal; !CherryPy will then work backward looking for a default handler as normal. In addition, the `_cp_dispatch` method is a list of remaining path segments, and the method is allowed to mutate it. For example, to handle the URI `/users/123/profile`, a `Users._cp_dispatch` method would receive a `vpath` argument of `['123', 'profile']`, at which point it could write:
+In previous versions, unexpected URI path segments, or unexpected parameters in the query string or request body, would generally return somewhat unhelpful "500 Server Error" responses. Starting in CherryPy 3.2, when query parameters passed to a handler are incorrect, or when path segments are incorrectly passed to a handler, "404 Not Found" is returned instead. When body params are incorrectly passed to a handler, "400 Bad Request" is returned.
+Beginning in !CherryPy 3.2, the "state" argument to `Bus.wait(state, interval)` may be a list or tuple, instead of a single state, in order to wake up on any of several states.
+Engine plugins, whether builtin or custom, may also now be configured if they are added to the engine object itself. The builtin plugins "autoreload", "thread_manager", "signal_handler", "timeout_monitor", and "console_control_handler" are already added. The "on" config entry subscribes or unsubscribes the plugin, and all other entries are set as attributes on the plugin instance.