Merge branch '1.3-branch'

6 files changed, 102 insertions, 53 deletions

diff --git a/docs/api/request.rst b/docs/api/request.rst
index 9596e5621..1ab84e230 100644
--- a/docs/api/request.rst
+++ b/docs/api/request.rst
@@ -208,9 +208,7 @@
        body associated with this request, this property will raise an
        exception.  See also :ref:`request_json_body`.
 
-   .. method:: set_property(func, name=None, reify=False)
-
-       .. versionadded:: 1.3
+   .. method:: set_property(callable, name=None, reify=False)
 
        Add a callable or a property descriptor to the request instance.
 
@@ -225,15 +223,15 @@
        cached. Thus the value of the property is only computed once for
        the lifetime of the object.
 
-       ``func`` can either be a callable that accepts the request as
+       ``callable`` can either be a callable that accepts the request as
        its single positional parameter, or it can be a property
        descriptor.
 
-       If the ``func`` is a property descriptor a ``ValueError`` will
-       be raised if ``name`` is ``None`` or ``reify`` is ``True``.
+       If the ``callable`` is a property descriptor a ``ValueError``
+       will be raised if ``name`` is ``None`` or ``reify`` is ``True``.
 
        If ``name`` is None, the name of the property will be computed
-       from the name of the ``func``.
+       from the name of the ``callable``.
 
        .. code-block:: python
           :linenos:
@@ -259,6 +257,8 @@
        without having to subclass it, which can be useful for extension
        authors.
 
+       .. versionadded:: 1.3
+
 .. note::
 
    For information about the API of a :term:`multidict` structure (such as
diff --git a/docs/glossary.rst b/docs/glossary.rst
index e4de15bd6..8307c0472 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -983,3 +983,15 @@ Glossary
       :meth:`pyramid.path.AssetResolver.resolve` method.  It supports the
       methods and attributes documented in
       :class:`pyramid.interfaces.IAssetDescriptor`.
+
+   Waitress
+      A :term:`WSGI` server that runs on UNIX and Windows under Python 2.6+
+      and Python 3.2+.  Projects generated via Pyramid scaffolding use
+      Waitress as a WGSI server.  See
+      http://docs.pylonsproject.org/projects/waitress/en/latest/ for detailed
+      information.
+
+   Green Unicorn
+      Aka ``gunicorn``, a fast :term:`WSGI` server that runs on UNIX under
+      Python 2.5+ (although at the time of this writing does not support
+      Python 3).  See http://gunicorn.org/ for detailed information.
diff --git a/docs/narr/firstapp.rst b/docs/narr/firstapp.rst
index 922b0ea82..1ca188d7e 100644
--- a/docs/narr/firstapp.rst
+++ b/docs/narr/firstapp.rst
@@ -22,17 +22,33 @@ Here's one of the very simplest :app:`Pyramid` applications:
 
 When this code is inserted into a Python script named ``helloworld.py`` and
 executed by a Python interpreter which has the :app:`Pyramid` software
-installed, an HTTP server is started on TCP port 8080:
+installed, an HTTP server is started on TCP port 8080.
+
+On UNIX:
+
+.. code-block:: text
+
+   $ /path/to/your/virtualenv/bin/python helloworld.py
+
+On Windows:
 
 .. code-block:: text
 
-   $ python helloworld.py
-   serving on 0.0.0.0:8080 view at http://127.0.0.1:8080
+   C:\> \path\to\your\virtualenv\Scripts\python.exe helloworld.py
 
+This command will not return and nothing will be printed to the console.
 When port 8080 is visited by a browser on the URL ``/hello/world``, the
-server will simply serve up the text "Hello world!"
+server will simply serve up the text "Hello world!".  If your application is
+running on your local system, using ``http://localhost:8080/hello/world``
+in a browser will show this result.
+
+Each time you visit a URL served by the application in a browser, a logging
+line will be emitted to the console displaying the hostname, the date, the
+request method and path, and some additional information.  This output is
+done by the wsgiref server we've used to serve this application.  It logs an
+"access log" in Apache combined logging format to the console.
 
-Press ``Ctrl-C`` to stop the application.
+Press ``Ctrl-C`` (or ``Ctrl-Break`` on Windows) to stop the application.
 
 Now that we have a rudimentary understanding of what the application does,
 let's examine it piece-by-piece.
@@ -210,16 +226,15 @@ which means "listen on all TCP interfaces."  By default, the HTTP server
 listens only on the ``127.0.0.1`` interface, which is problematic if you're
 running the server on a remote system and you wish to access it with a web
 browser from a local system.  We also specify a TCP port number to listen on,
-which is 8080, passing it as the second argument.  The final argument ios ,
-passing it the ``app`` object (a :term:`router`), which is the the
-application we wish to serve.  Finally, we call the server's
-``serve_forever`` method, which starts the main loop in which it will wait
-for requests from the outside world.
+which is 8080, passing it as the second argument.  The final argument is the
+``app`` object (a :term:`router`), which is the the application we wish to
+serve.  Finally, we call the server's ``serve_forever`` method, which starts
+the main loop in which it will wait for requests from the outside world.
 
 When this line is invoked, it causes the server to start listening on TCP
 port 8080.  The server will serve requests forever, or at least until we stop
-it by killing the process which runs it (usually by pressing ``Ctrl-C`` in
-the terminal we used to start it).
+it by killing the process which runs it (usually by pressing ``Ctrl-C``
+or ``Ctrl-Break`` in the terminal we used to start it).
 
 Conclusion
 ~~~~~~~~~~
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 896b65249..5696b0b73 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -881,37 +881,54 @@ configuration as would be loaded if you were running your Pyramid application
 via ``pserve``.  This can be a useful debugging tool.  See
 :ref:`interactive_shell` for more details.
 
-.. _alternate_wsgi_server:
+What Is This ``pserve`` Thing
+-----------------------------
 
-Using an Alternate WSGI Server
-------------------------------
-
-The code generated by :app:`Pyramid` scaffolding assumes that you will be
+The code generated by an :app:`Pyramid` scaffold assumes that you will be
 using the ``pserve`` command to start your application while you do
-development.  The default rendering of Pyramid scaffolding uses the
-*waitress* WSGI server, which is a server that is suited for production
-usage.  It's not very fast, or very featureful: its main feature is that it
-works on all platforms and all systems, making it a good choice as a default
-server from the perspective of Pyramid's developers.
+development.  ``pserve`` is a command that reads a :term:`PasteDeploy`
+``.ini`` file (e.g. ``development.ini``) and configures a server to serve a
+Pyramid application based on the data in the file.
 
 ``pserve`` is by no means the only way to start up and serve a :app:`Pyramid`
 application.  As we saw in :ref:`firstapp_chapter`, ``pserve`` needn't be
 invoked at all to run a :app:`Pyramid` application.  The use of ``pserve`` to
 run a :app:`Pyramid` application is purely conventional based on the output
-of its scaffold.
-
-Any :term:`WSGI` server is capable of running a :app:`Pyramid` application.
-Some WSGI servers don't require the :term:`PasteDeploy` framework's
-``pserve`` command to do server process management at all.  Each :term:`WSGI`
-server has its own documentation about how it creates a process to run an
-application, and there are many of them, so we cannot provide the details for
-each here.  But the concepts are largely the same, whatever server you happen
-to use.
-
-One popular production alternative to a ``pserve``-invoked server is
-:term:`mod_wsgi`. You can also use :term:`mod_wsgi` to serve your
-:app:`Pyramid` application using the Apache web server rather than any
-"pure-Python" server that is started as a result of ``pserve``.  See
-:ref:`modwsgi_tutorial` for details.  However, it is usually easier to
-*develop* an application using a ``pserve`` -invoked webserver, as
-exception and debugging output will be sent to the console.
+of its scaffolding.  But we strongly recommend using while developing your
+application, because many other convenience introspection commands (such as
+``pviews``, ``prequest``, ``proutes`` and others) are also implemented in
+terms of configuration availaibility of this ``.ini`` file format.  It also
+configures Pyramid logging and provides the ``--reload`` switch for
+convenient restarting of the server when code changes.
+
+.. _alternate_wsgi_server:
+
+Using an Alternate WSGI Server
+------------------------------
+
+Pyramid scaffolds generate projects which use the :term:`Waitress` WSGI
+server.  Waitress is a server that is suited for development and light
+production usage.  It's not the fastest nor the most featureful WSGI server.
+Instead, its main feature is that it works on all platforms that Pyramid
+needs to run on, making it a good choice as a default server from the
+perspective of Pyramid's developers.  
+
+Any WSGI server is capable of running a :app:`Pyramid` application.  But we
+suggest you stick with the default server for development, and that you wait
+to investigate other server options until you're ready to deploy your
+application to production.  Unless for some reason you need to develop on a
+non-local system, investigating alternate server options is usually a
+distraction until you're ready to deploy.  But we recommend developing using
+the default configuration on a local system that you have complete control
+over; it will provide the best development experience.
+
+One popular production alternative to the default Waitress server is
+:term:`mod_wsgi`. You can use mod_wsgi to serve your :app:`Pyramid`
+application using the Apache web server rather than any "pure-Python" server
+like Waitress.  It is fast and featureful.  See :ref:`modwsgi_tutorial` for
+details.
+
+Another good production alternative is :term:`Green Unicorn` (aka
+``gunicorn``).  It's faster than Waitress and slightly easier to configure
+than mod_wsgi, although it depends, in its default configuration, on having a
+buffering HTTP proxy in front of it.
diff --git a/docs/tutorials/wiki2/definingmodels.rst b/docs/tutorials/wiki2/definingmodels.rst
index cd295e993..2b8932a98 100644
--- a/docs/tutorials/wiki2/definingmodels.rst
+++ b/docs/tutorials/wiki2/definingmodels.rst
@@ -63,10 +63,10 @@ script.  In particular, we'll replace our import of ``MyModel`` with one of
 ``Page`` and we'll change the very end of the script to create a ``Page``
 rather than a ``MyModel`` and add it to our ``DBSession``.
 
-The result of all of our edits to ``models.py`` will end up looking
+The result of all of our edits to ``populate.py`` will end up looking
 something like this:
 
-.. literalinclude:: src/models/tutorial/models.py
+.. literalinclude:: src/models/tutorial/scripts/populate.py
    :linenos:
    :language: python
 
diff --git a/docs/whatsnew-1.3.rst b/docs/whatsnew-1.3.rst
index eb8617ff1..ee4e2ccb5 100644
--- a/docs/whatsnew-1.3.rst
+++ b/docs/whatsnew-1.3.rst
@@ -198,11 +198,16 @@ Extending a Request without Subclassing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It is now possible to extend a :class:`pyramid.request.Request` object
-with property descriptors without having to create a subclass via
-:meth:`pyramid.request.Request.set_property`. New properties may be
-reified, effectively caching the value for the lifetime of the instance.
-Common use-cases for this would be to get a database connection for the
-request or identify the current user.
+with property descriptors without having to create a custom request factory.
+The new method :meth:`pyramid.config.Configurator.set_request_property`
+provides an entry point for addons to register properties which will be
+added to each request. New properties may be reified, effectively caching
+the return value for the lifetime of the instance. Common use-cases for this
+would be to get a database connection for the request or identify the current
+user. The new method :meth:`pyramid.request.Request.set_property` has been
+added, as well, but the configurator method should be preferred as it
+provides conflict detection and consistency in the lifetime of the
+properties.
 
 Minor Feature Additions
 -----------------------