Merge pull request #2922 from stevepiercy/1.8-branch

Steve Piercy

2017-01-26 c186b0e0acb03f0dbf4c40c0e05190d02f36dbe8

Merge pull request #2922 from stevepiercy/1.8-branch

grammar fix

 docs/narr/project.rst

@@ -37,7 +37,7 @@
:app:`Pyramid` cookiecutters
----------------------------

Pyramid cookiecutters released under the Pylons Project include differ from each other on a number of axes:
Pyramid cookiecutters released under the Pylons Project differ from each other on a number of axes:

- the persistence mechanism they offer (no persistence mechanism, :term:`SQLAlchemy` with SQLite, or :term:`ZODB`)

@@ -1105,17 +1105,17 @@
During development, it can be really useful to automatically have the
webserver restart when you make changes. ``pserve`` has a ``--reload`` switch
to enable this. It uses the
`hupper <http://docs.pylonsproject.org/projects/hupper/en/latest/>` package
`hupper <http://docs.pylonsproject.org/projects/hupper/en/latest/>`_ package
to enable this behavior. When your code crashes, ``hupper`` will wait for
another change or the ``SIGHUP`` signal before restarting again.

inotify support
~~~~~~~~~~~~~~~

By default, ``hupper`` will poll the filesystem for changes to all python
By default ``hupper`` will poll the filesystem for changes to all Python
code. This can be pretty inefficient in larger projects. To be nicer to your
hard drive, you should install the
`watchdog <http://pythonhosted.org/watchdog/>` package in development.
`watchdog <http://pythonhosted.org/watchdog/>`_ package in development.
``hupper`` will automatically use ``watchdog`` to more efficiently poll the
filesystem.

@@ -1124,11 +1124,11 @@

By default, ``pserve --reload`` will monitor all imported Python code
(everything in ``sys.modules``) as well as the config file passed to
``pserve`` (e.g. ``development.ini``). You can instruct ``pserve`` to watch
``pserve`` (e.g., ``development.ini``). You can instruct ``pserve`` to watch
other files for changes as well by defining a ``[pserve]`` section in your
configuration file. For example, let's say your application loads the
``favicon.ico`` file at startup and stores it in memory to efficiently
serve it many times. When you change it you want ``pserve`` to restart:
serve it many times. When you change it, you want ``pserve`` to restart:

.. code-block:: ini

@@ -1137,6 +1137,6 @@
        myapp/static/favicon.ico

Paths may be absolute or relative to the configuration file. They may also
be an :term:`asset specification`. These paths are passed to ``hupper`` which
be an :term:`asset specification`. These paths are passed to ``hupper``, which
has some basic support for globbing. Acceptable glob patterns depend on the
version of Python being used.