Merge branch 'master' into one_cc

34 files changed, 155 insertions, 111 deletions

diff --git a/docs/api/config.rst b/docs/api/config.rst
index a785b64ad..b2cd53a68 100644
--- a/docs/api/config.rst
+++ b/docs/api/config.rst
@@ -44,7 +44,6 @@
    :methodcategory:`Extending the Request Object`
 
      .. automethod:: add_request_method
-     .. automethod:: set_request_property
 
    :methodcategory:`Using I18N`
 
diff --git a/docs/api/request.rst b/docs/api/request.rst
index b5700f4ab..0c169adaf 100644
--- a/docs/api/request.rst
+++ b/docs/api/request.rst
@@ -228,8 +228,7 @@
         handed.
 
       - sets request extensions (such as those added via
-        :meth:`~pyramid.config.Configurator.add_request_method` or
-        :meth:`~pyramid.config.Configurator.set_request_property`) on the
+        :meth:`~pyramid.config.Configurator.add_request_method`) on the
         request it's passed.
 
       - causes a :class:`~pyramid.events.NewRequest` event to be sent at the
diff --git a/docs/api/session.rst b/docs/api/session.rst
index 53bae7c52..d0cb112ec 100644
--- a/docs/api/session.rst
+++ b/docs/api/session.rst
@@ -5,15 +5,11 @@
 
 .. automodule:: pyramid.session
 
-  .. autofunction:: signed_serialize
-
-  .. autofunction:: signed_deserialize
-
   .. autofunction:: SignedCookieSessionFactory
 
-  .. autofunction:: UnencryptedCookieSessionFactoryConfig
-
   .. autofunction:: BaseCookieSessionFactory
 
   .. autoclass:: PickleSerializer
 
+  .. autoclass:: JSONSerializer
+
diff --git a/docs/conf.py b/docs/conf.py
index 8fe7108ff..6e3d41240 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -161,6 +161,15 @@ html_theme_options = dict(
     outdated='false',
     )
 
+# Control display of sidebars
+html_sidebars = {'**': [
+    'localtoc.html',
+    'ethicalads.html',
+    'relations.html',
+    'sourcelink.html',
+    'searchbox.html',
+]}
+
 # The name for this set of Sphinx documents.  If None, it defaults to
 # "<project> v<release> documentation".
 html_title = 'The Pyramid Web Framework v%s' % release
diff --git a/docs/glossary.rst b/docs/glossary.rst
index ae7d4cf42..8f94eeaca 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -343,7 +343,7 @@ Glossary
      full-featured Python web framework.
 
    Grok
-     `A web framework based on Zope 3 <http://grok.zope.org>`_.
+     `A web framework based on Zope 3 <https://web.archive.org/web/20180615015013/http://grok.zope.org>`_.
 
    Django
      `A full-featured Python web framework <https://www.djangoproject.com/>`_.
@@ -853,7 +853,7 @@ Glossary
    Localization
      The process of displaying the user interface of an
      internationalized application in a particular language or
-     cultural context.  Often shortened to "l10" (because the word
+     cultural context.  Often shortened to "l10n" (because the word
      "localization" is L, 10 letters, then N).
 
      .. seealso::
@@ -1083,7 +1083,7 @@ Glossary
 
    Green Unicorn
       Aka ``gunicorn``, a fast :term:`WSGI` server that runs on Unix under
-      Python 2.6+ or Python 3.1+.  See http://gunicorn.org/ for detailed 
+      Python 2.6+ or Python 3.1+.  See https://gunicorn.org/ for detailed
       information.
 
    predicate factory
diff --git a/docs/index.rst b/docs/index.rst
index 76d23b4f4..19cff9414 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -66,7 +66,7 @@ Official tutorials provide a quick overview of :app:`Pyramid`'s features in more
 Support and Development
 =======================
 
-The `Pyramid website <https://trypyramid.com/resources.html>`_ is the main
+The `Pyramid website <https://trypyramid.com/documentation.html>`_ is the main
 entry point to :app:`Pyramid` web framework resources for support and
 development information.
 
diff --git a/docs/narr/advconfig.rst b/docs/narr/advconfig.rst
index 880e538f1..322741648 100644
--- a/docs/narr/advconfig.rst
+++ b/docs/narr/advconfig.rst
@@ -299,7 +299,6 @@ These are the methods of the configurator which provide conflict detection:
 :meth:`~pyramid.config.Configurator.add_request_method`,
 :meth:`~pyramid.config.Configurator.set_request_factory`,
 :meth:`~pyramid.config.Configurator.set_session_factory`,
-:meth:`~pyramid.config.Configurator.set_request_property`,
 :meth:`~pyramid.config.Configurator.set_root_factory`,
 :meth:`~pyramid.config.Configurator.set_view_mapper`,
 :meth:`~pyramid.config.Configurator.set_authentication_policy`,
diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst
index cc1ecdbee..dada4e8bd 100644
--- a/docs/narr/introduction.rst
+++ b/docs/narr/introduction.rst
@@ -52,7 +52,7 @@ Modern
 Tested
 ~~~~~~
 
-Untested code is broken by design. The :app:`Pyramid` community has a strong testing culture and our framework reflects that. Every release of :app:`Pyramid` has 100% statement coverage (as measured by `coverage <https://coverage.readthedocs.io/en/latest/>`_) and 95% decision/condition coverage. (as measured by `instrumental <https://instrumental.readthedocs.io/en/latest/intro.html>`_) It is automatically tested using `Travis <https://travis-ci.org/Pylons/pyramid>`_ and `Jenkins <http://jenkins.pylonsproject.org/job/pyramid/>`_ on supported versions of Python after each commit to its GitHub repository. `Official Pyramid add-ons <https://trypyramid.com/resources-extending-pyramid.html>`_ are held to a similar testing standard.
+Untested code is broken by design. The :app:`Pyramid` community has a strong testing culture and our framework reflects that. Every release of :app:`Pyramid` has 100% statement coverage (as measured by `coverage <https://coverage.readthedocs.io/en/latest/>`_) and 95% decision/condition coverage. (as measured by `instrumental <https://instrumental.readthedocs.io/en/latest/intro.html>`_) It is automatically tested using `Travis <https://travis-ci.org/Pylons/pyramid>`_ and `Jenkins <http://jenkins.pylonsproject.org/job/pyramid/>`_ on supported versions of Python after each commit to its GitHub repository. `Official Pyramid add-ons <https://trypyramid.com/extending-pyramid.html>`_ are held to a similar testing standard.
 
 We still find bugs in :app:`Pyramid`, but we've noticed we find a lot fewer of them while working on projects with a solid testing regime.
 
@@ -173,7 +173,7 @@ Supported :app:`Pyramid` add-ons are held to the same demanding standards as the
 
 .. seealso::
 
-    See also https://trypyramid.com/resources-extending-pyramid.html
+    See also https://trypyramid.com/extending-pyramid.html
 
 Write your views, *your* way
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 5560b02c0..84fd8e31f 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -242,26 +242,26 @@ On Windows:
     %VENV%\Scripts\pip install -e ".[testing]"
 
 Once the testing requirements are installed, then you can run the tests using
-the ``py.test`` command that was just installed in the ``bin`` directory of
+the ``pytest`` command that was just installed in the ``bin`` directory of
 your virtual environment.
 
 On Unix:
 
 .. code-block:: bash
 
-    $VENV/bin/py.test -q
+    $VENV/bin/pytest -q
 
 On Windows:
 
 .. code-block:: doscon
 
-    %VENV%\Scripts\py.test -q
+    %VENV%\Scripts\pytest -q
 
 Here's sample output from a test run on Unix:
 
 .. code-block:: bash
 
-    $VENV/bin/py.test -q
+    $VENV/bin/pytest -q
     ..
     2 passed in 0.47 seconds
 
@@ -269,28 +269,28 @@ The tests themselves are found in the ``tests.py`` module in your ``cookiecutter
 
 .. note::
 
-    The ``-q`` option is passed to the ``py.test`` command to limit the output
+    The ``-q`` option is passed to the ``pytest`` command to limit the output
     to a stream of dots. If you don't pass ``-q``, you'll see verbose test
     result output (which normally isn't very useful).
 
 Alternatively, if you'd like to see test coverage, pass the ``--cov`` option
-to ``py.test``:
+to ``pytest``:
 
 .. code-block:: bash
 
-    $VENV/bin/py.test --cov -q
+    $VENV/bin/pytest --cov -q
 
-Cookiecutters include configuration defaults for ``py.test`` and test coverage.
+Cookiecutters include configuration defaults for ``pytest`` and test coverage.
 These configuration files are ``pytest.ini`` and ``.coveragerc``, located at
 the root of your package. Without these defaults, we would need to specify the
 path to the module on which we want to run tests and coverage.
 
 .. code-block:: bash
 
-    $VENV/bin/py.test --cov=myproject myproject/tests.py -q
+    $VENV/bin/pytest --cov=myproject myproject/tests.py -q
 
-.. seealso:: See py.test's documentation for :ref:`pytest:usage` or invoke
-   ``py.test -h`` to see its full set of options.
+.. seealso:: See ``pytest``'s documentation for :ref:`pytest:usage` or invoke
+   ``pytest -h`` to see its full set of options.
 
 
 .. index::
@@ -1047,7 +1047,7 @@ The ``tests.py`` module includes tests for your application.
    :linenos:
 
 This sample ``tests.py`` file has one unit test and one functional test defined
-within it. These tests are executed when you run ``py.test -q``. You may add
+within it. These tests are executed when you run ``pytest -q``. You may add
 more tests here as you build your application. You are not required to write
 tests to use :app:`Pyramid`. This file is simply provided for convenience and
 example.
diff --git a/docs/narr/sessions.rst b/docs/narr/sessions.rst
index 2d80b1a63..ded7e87e3 100644
--- a/docs/narr/sessions.rst
+++ b/docs/narr/sessions.rst
@@ -59,25 +59,68 @@ using the :meth:`pyramid.config.Configurator.set_session_factory` method.
    By default the :func:`~pyramid.session.SignedCookieSessionFactory`
    implementation contains the following security concerns:
 
-   - Session data is *unencrypted*.  You should not use it when you keep
-     sensitive information in the session object, as the information can be
-     easily read by both users of your application and third parties who have
-     access to your users' network traffic.
-
-   - If you use this sessioning implementation, and you inadvertently create a
-     cross-site scripting vulnerability in your application, because the
-     session data is stored unencrypted in a cookie, it will also be easier for
-     evildoers to obtain the current user's cross-site scripting token.
-
-   - The default serialization method, while replaceable with something like
-     JSON, is implemented using pickle which can lead to remote code execution
-     if your secret key is compromised.
-
-   In short, use a different session factory implementation (preferably one
-   which keeps session data on the server) for anything but the most basic of
-   applications where "session security doesn't matter", you are sure your
-   application has no cross-site scripting vulnerabilities, and you are confident
-   your secret key will not be exposed.
+   - Session data is *unencrypted* (but it is signed / authenticated).
+
+     This means an attacker cannot change the session data, but they can view it.
+     You should not use it when you keep sensitive information in the session object, as the information can be easily read by both users of your application and third parties who have access to your users' network traffic.
+
+     At the very least, use TLS and set ``secure=True`` to avoid arbitrary users on the network from viewing the session contents.
+
+   - If you use this sessioning implementation, and you inadvertently create a cross-site scripting vulnerability in your application, because the session data is stored unencrypted in a cookie, it will also be easier for evildoers to obtain the current user's cross-site scripting token.
+
+     Set ``httponly=True`` to mitigate this vulnerability by hiding the cookie from client-side JavaScript.
+
+   - The default serialization method, while replaceable with something like JSON, is implemented using pickle which can lead to remote code execution if your secret key is compromised.
+
+     To mitigate this, set ``serializer=pyramid.session.JSONSerializer()`` to use :class:`pyramid.session.JSONSerializer`. This option will be the default in :app:`Pyramid` 2.0.
+     See :ref:`pickle_session_deprecation` for more information about this change.
+
+   In short, use a different session factory implementation (preferably one which keeps session data on the server) for anything but the most basic of applications where "session security doesn't matter", you are sure your application has no cross-site scripting vulnerabilities, and you are confident your secret key will not be exposed.
+
+.. index::
+    triple: pickle deprecation; JSON-serializable; ISession interface
+
+.. _pickle_session_deprecation:
+
+Upcoming Changes to ISession in Pyramid 2.0
+-------------------------------------------
+
+In :app:`Pyramid` 2.0 the :class:`pyramid.interfaces.ISession` interface will be changing to require that session implementations only need to support JSON-serializable data types.
+This is a stricter contract than the current requirement that all objects be pickleable and it is being done for security purposes.
+This is a backward-incompatible change.
+Currently, if a client-side session implementation is compromised, it leaves the application vulnerable to remote code execution attacks using specially-crafted sessions that execute code when deserialized.
+
+For users with compatibility concerns, it's possible to craft a serializer that can handle both formats until you are satisfied that clients have had time to reasonably upgrade.
+Remember that sessions should be short-lived and thus the number of clients affected should be small (no longer than an auth token, at a maximum). An example serializer:
+
+.. code-block:: python
+    :linenos:
+
+    from pyramid.session import JSONSerializer
+    from pyramid.session import PickleSerializer
+    from pyramid.session import SignedCookieSessionFactory
+
+    class JSONSerializerWithPickleFallback(object):
+        def __init__(self):
+            self.json = JSONSerializer()
+            self.pickle = PickleSerializer()
+
+        def dumps(self, value):
+            # maybe catch serialization errors here and keep using pickle
+            # while finding spots in your app that are not storing
+            # JSON-serializable objects, falling back to pickle
+            return self.json.dumps(value)
+
+        def loads(self, value):
+            try:
+                return self.json.loads(value)
+            except ValueError:
+                return self.pickle.loads(value)
+
+    # somewhere in your configuration code
+    serializer = JSONSerializerWithPickleFallback()
+    session_factory = SignedCookieSessionFactory(..., serializer=serializer)
+    config.set_session_factory(session_factory)
 
 .. index::
    single: session object
@@ -139,7 +182,7 @@ Some gotchas:
   that they are instances of basic types of objects, such as strings, lists,
   dictionaries, tuples, integers, etc.  If you place an object in a session
   data key or value that is not pickleable, an error will be raised when the
-  session is serialized.
+  session is serialized. Please also see :ref:`pickle_session_deprecation`.
 
 - If you place a mutable value (for example, a list or a dictionary) in a
   session object, and you subsequently mutate that value, you must call the
diff --git a/docs/narr/subrequest.rst b/docs/narr/subrequest.rst
index 9094c7d83..03f372446 100644
--- a/docs/narr/subrequest.rst
+++ b/docs/narr/subrequest.rst
@@ -232,8 +232,7 @@ unconditionally does the following:
   callable) to the request object to which it is handed.
 
 - It sets request extensions (such as those added via
-  :meth:`~pyramid.config.Configurator.add_request_method` or
-  :meth:`~pyramid.config.Configurator.set_request_property`) on the subrequest
+  :meth:`~pyramid.config.Configurator.add_request_method`) on the subrequest
   object passed as ``request``.
 
 - It causes a :class:`~pyramid.events.NewRequest` event to be sent at the
diff --git a/docs/narr/testing.rst b/docs/narr/testing.rst
index ad4ba2186..8048ca62c 100644
--- a/docs/narr/testing.rst
+++ b/docs/narr/testing.rst
@@ -275,7 +275,7 @@ without needing to invoke the actual application configuration implied by its
            
 In the above example, we create a ``MyTest`` test case that inherits from
 :class:`unittest.TestCase`.  If it's in our :app:`Pyramid` application, it will
-be found when ``py.test`` is run.  It has two test methods.
+be found when ``pytest`` is run.  It has two test methods.
 
 The first test method, ``test_view_fn_forbidden`` tests the ``view_fn`` when
 the authentication policy forbids the current user the ``edit`` permission. Its
@@ -365,7 +365,7 @@ Functional tests test your literal application.
 
 In Pyramid, functional tests are typically written using the :term:`WebTest`
 package, which provides APIs for invoking HTTP(S) requests to your application.
-We also like ``py.test`` and ``pytest-cov`` to provide simple testing and
+We also like ``pytest`` and ``pytest-cov`` to provide simple testing and
 coverage reports.
 
 Regardless of which testing :term:`package` you use, be sure to add a
diff --git a/docs/quick_tour.rst b/docs/quick_tour.rst
index ce0fed275..05c2ed7f6 100644
--- a/docs/quick_tour.rst
+++ b/docs/quick_tour.rst
@@ -680,8 +680,8 @@ the relevant ``.ini`` configuration file.
     :ref:`Quick Tutorial pyramid_debugtoolbar <qtut_debugtoolbar>` and
     :ref:`pyramid_debugtoolbar <toolbar:overview>`
 
-Unit tests and ``py.test``
-==========================
+Unit tests and ``pytest``
+=========================
 
 Yikes! We got this far and we haven't yet discussed tests. This is particularly
 egregious, as Pyramid has had a deep commitment to full test coverage since
@@ -689,7 +689,7 @@ before its release.
 
 Our ``pyramid-cookiecutter-starter`` cookiecutter generated a ``tests.py`` module with
 one unit test and one functional test in it. It also configured ``setup.py`` with test requirements:
-``py.test`` as the test runner, ``WebTest`` for running view tests, and the
+``pytest`` as the test runner, ``WebTest`` for running view tests, and the
 ``pytest-cov`` tool which yells at us for code that isn't tested:
 
 .. literalinclude:: quick_tour/package/setup.py
@@ -706,7 +706,7 @@ We already installed the test requirements when we ran the command ``$VENV/bin/p
 
 .. code-block:: bash
 
-    $VENV/bin/py.test --cov --cov-report=term-missing
+    $VENV/bin/pytest --cov --cov-report=term-missing
 
 This yields the following output.
 
diff --git a/docs/quick_tutorial/databases.rst b/docs/quick_tutorial/databases.rst
index 2e656f565..dcf411d23 100644
--- a/docs/quick_tutorial/databases.rst
+++ b/docs/quick_tutorial/databases.rst
@@ -128,11 +128,11 @@ Steps
    .. literalinclude:: databases/tutorial/tests.py
        :linenos:
 
-#. Run the tests in your package using ``py.test``:
+#. Run the tests in your package using ``pytest``:
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ..
        2 passed in 1.41 seconds
 
diff --git a/docs/quick_tutorial/forms.rst b/docs/quick_tutorial/forms.rst
index be745764b..f064a4baf 100644
--- a/docs/quick_tutorial/forms.rst
+++ b/docs/quick_tutorial/forms.rst
@@ -91,7 +91,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ..
        2 passed in 0.45 seconds
 
diff --git a/docs/quick_tutorial/functional_testing.rst b/docs/quick_tutorial/functional_testing.rst
index fa56b4589..7c4dcee26 100644
--- a/docs/quick_tutorial/functional_testing.rst
+++ b/docs/quick_tutorial/functional_testing.rst
@@ -53,7 +53,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ..
        2 passed in 0.25 seconds
 
diff --git a/docs/quick_tutorial/jinja2.rst b/docs/quick_tutorial/jinja2.rst
index 87122a374..6c33e406e 100644
--- a/docs/quick_tutorial/jinja2.rst
+++ b/docs/quick_tutorial/jinja2.rst
@@ -50,7 +50,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ....
        4 passed in 0.40 seconds
 
diff --git a/docs/quick_tutorial/json.rst b/docs/quick_tutorial/json.rst
index 98283424c..44d1de8cb 100644
--- a/docs/quick_tutorial/json.rst
+++ b/docs/quick_tutorial/json.rst
@@ -54,7 +54,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        .....
        5 passed in 0.47 seconds
 
diff --git a/docs/quick_tutorial/logging.rst b/docs/quick_tutorial/logging.rst
index ccbb7970f..f4a368bfa 100644
--- a/docs/quick_tutorial/logging.rst
+++ b/docs/quick_tutorial/logging.rst
@@ -54,7 +54,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ....
        4 passed in 0.41 seconds
 
diff --git a/docs/quick_tutorial/more_view_classes.rst b/docs/quick_tutorial/more_view_classes.rst
index 15452e9ae..684fb1c43 100644
--- a/docs/quick_tutorial/more_view_classes.rst
+++ b/docs/quick_tutorial/more_view_classes.rst
@@ -105,7 +105,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ..
        2 passed in 0.40 seconds
 
diff --git a/docs/quick_tutorial/request_response.rst b/docs/quick_tutorial/request_response.rst
index 098753820..f7753f222 100644
--- a/docs/quick_tutorial/request_response.rst
+++ b/docs/quick_tutorial/request_response.rst
@@ -61,7 +61,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        .....
        5 passed in 0.30 seconds
 
diff --git a/docs/quick_tutorial/routing.rst b/docs/quick_tutorial/routing.rst
index 0384892b2..a6538a75f 100644
--- a/docs/quick_tutorial/routing.rst
+++ b/docs/quick_tutorial/routing.rst
@@ -79,7 +79,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ..
        2 passed in 0.39 seconds
 
diff --git a/docs/quick_tutorial/sessions.rst b/docs/quick_tutorial/sessions.rst
index d67a5063a..8a67d6a0f 100644
--- a/docs/quick_tutorial/sessions.rst
+++ b/docs/quick_tutorial/sessions.rst
@@ -60,7 +60,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ....
        4 passed in 0.42 seconds
 
diff --git a/docs/quick_tutorial/static_assets.rst b/docs/quick_tutorial/static_assets.rst
index 7a6b5dac3..567328307 100644
--- a/docs/quick_tutorial/static_assets.rst
+++ b/docs/quick_tutorial/static_assets.rst
@@ -54,7 +54,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ....
        5 passed in 0.50 seconds
 
diff --git a/docs/quick_tutorial/templating.rst b/docs/quick_tutorial/templating.rst
index 3fbef699c..4d4ccea4f 100644
--- a/docs/quick_tutorial/templating.rst
+++ b/docs/quick_tutorial/templating.rst
@@ -92,7 +92,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ....
        4 passed in 0.46 seconds
 
diff --git a/docs/quick_tutorial/unit_testing.rst b/docs/quick_tutorial/unit_testing.rst
index 09e3ea197..48cffd0e1 100644
--- a/docs/quick_tutorial/unit_testing.rst
+++ b/docs/quick_tutorial/unit_testing.rst
@@ -62,7 +62,7 @@ Steps
    .. code-block:: bash
 
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        .
        1 passed in 0.14 seconds
 
@@ -96,7 +96,7 @@ Extra credit
 ============
 
 #. Change the test to assert that the response status code should be ``404``
-   (meaning, not found). Run ``py.test`` again. Read the error report and see
+   (meaning, not found). Run ``pytest`` again. Read the error report and see
    if you can decipher what it is telling you.
 
 #. As a more realistic example, put the ``tests.py`` back as you found it, and
diff --git a/docs/quick_tutorial/view_classes.rst b/docs/quick_tutorial/view_classes.rst
index fc7ba5125..4b7b78140 100644
--- a/docs/quick_tutorial/view_classes.rst
+++ b/docs/quick_tutorial/view_classes.rst
@@ -61,7 +61,7 @@ Steps
 
    .. code-block:: bash
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ....
        4 passed in 0.34 seconds
 
diff --git a/docs/quick_tutorial/views.rst b/docs/quick_tutorial/views.rst
index f7fa64719..45bc8518b 100644
--- a/docs/quick_tutorial/views.rst
+++ b/docs/quick_tutorial/views.rst
@@ -68,7 +68,7 @@ Steps
    .. code-block:: bash
 
 
-       $VENV/bin/py.test tutorial/tests.py -q
+       $VENV/bin/pytest tutorial/tests.py -q
        ....
        4 passed in 0.28 seconds
 
diff --git a/docs/tutorials/wiki/installation.rst b/docs/tutorials/wiki/installation.rst
index 2502c47b6..d0037e584 100644
--- a/docs/tutorials/wiki/installation.rst
+++ b/docs/tutorials/wiki/installation.rst
@@ -205,22 +205,22 @@ Run the tests
 
 After you've installed the project in development mode as well as the testing
 requirements, you may run the tests for the project. The following commands
-provide options to py.test that specify the module for which its tests shall be
-run, and to run py.test in quiet mode.
+provide options to ``pytest`` that specify the module for which its tests shall be
+run, and to run ``pytest`` in quiet mode.
 
 On Unix
 ^^^^^^^
 
 .. code-block:: bash
 
-    $VENV/bin/py.test -q
+    $VENV/bin/pytest -q
 
 On Windows
 ^^^^^^^^^^
 
 .. code-block:: doscon
 
-    %VENV%\Scripts\py.test -q
+    %VENV%\Scripts\pytest -q
 
 For a successful test run, you should see output that ends like this:
 
@@ -233,8 +233,8 @@ For a successful test run, you should see output that ends like this:
 Expose test coverage information
 --------------------------------
 
-You can run the ``py.test`` command to see test coverage information. This
-runs the tests in the same way that ``py.test`` does, but provides additional
+You can run the ``pytest`` command to see test coverage information. This
+runs the tests in the same way that ``pytest`` does, but provides additional
 :term:`coverage` information, exposing which lines of your project are covered by the
 tests.
 
@@ -246,14 +246,14 @@ On Unix
 
 .. code-block:: bash
 
-    $VENV/bin/py.test --cov --cov-report=term-missing
+    $VENV/bin/pytest --cov --cov-report=term-missing
 
 On Windows
 ^^^^^^^^^^
 
 .. code-block:: doscon
 
-    %VENV%\Scripts\py.test --cov --cov-report=term-missing
+    %VENV%\Scripts\pytest --cov --cov-report=term-missing
 
 If successful, you will see output something like this:
 
@@ -285,7 +285,7 @@ Our package doesn't quite have 100% test coverage.
 Test and coverage cookiecutter defaults
 ---------------------------------------
 
-The Pyramid cookiecutter includes configuration defaults for ``py.test`` and
+The Pyramid cookiecutter includes configuration defaults for ``pytest`` and
 test coverage.  These configuration files are ``pytest.ini`` and
 ``.coveragerc``, located at the root of your package. Without these defaults,
 we would need to specify the path to the module on which we want to run tests
@@ -296,22 +296,22 @@ On Unix
 
 .. code-block:: bash
 
-    $VENV/bin/py.test --cov=tutorial tutorial/tests.py -q
+    $VENV/bin/pytest --cov=tutorial tutorial/tests.py -q
 
 On Windows
 ^^^^^^^^^^
 
 .. code-block:: doscon
 
-    %VENV%\Scripts\py.test --cov=tutorial tutorial\tests.py -q
+    %VENV%\Scripts\pytest --cov=tutorial tutorial\tests.py -q
 
-py.test follows :ref:`conventions for Python test discovery
+``pytest`` follows :ref:`conventions for Python test discovery
 <pytest:test discovery>`, and the configuration defaults from the cookiecutter
-tell ``py.test`` where to find the module on which we want to run tests and
+tell ``pytest`` where to find the module on which we want to run tests and
 coverage.
 
-.. seealso:: See py.test's documentation for :ref:`pytest:usage` or invoke
-   ``py.test -h`` to see its full set of options.
+.. seealso:: See ``pytest``'s documentation for :ref:`pytest:usage` or invoke
+   ``pytest -h`` to see its full set of options.
 
 
 .. _wiki-start-the-application:
diff --git a/docs/tutorials/wiki/tests.rst b/docs/tutorials/wiki/tests.rst
index 353813e91..fdd218add 100644
--- a/docs/tutorials/wiki/tests.rst
+++ b/docs/tutorials/wiki/tests.rst
@@ -52,22 +52,22 @@ follows:
 Running the tests
 =================
 
-We can run these tests by using ``py.test`` similarly to how we did in
+We can run these tests by using ``pytest`` similarly to how we did in
 :ref:`running_tests`. Courtesy of the cookiecutter, our testing dependencies have
-already been satisfied and ``py.test`` and coverage have already been
+already been satisfied and ``pytest`` and coverage have already been
 configured, so we can jump right to running tests.
 
 On Unix:
 
 .. code-block:: bash
 
-    $VENV/bin/py.test -q
+    $VENV/bin/pytest -q
 
 On Windows:
 
 .. code-block:: doscon
 
-    %VENV%\Scripts\py.test -q
+    %VENV%\Scripts\pytest -q
 
 The expected result should look like the following:
 
diff --git a/docs/tutorials/wiki2/definingviews.rst b/docs/tutorials/wiki2/definingviews.rst
index b73338f52..d10d862f5 100644
--- a/docs/tutorials/wiki2/definingviews.rst
+++ b/docs/tutorials/wiki2/definingviews.rst
@@ -149,7 +149,7 @@ We'll describe each one briefly in the following sections.
 
 .. note::
 
-  There is nothing special about the filename ``default.py`` exept that it is a
+  There is nothing special about the filename ``default.py`` except that it is a
   Python module. A project may have many view callables throughout its codebase
   in arbitrarily named modules. Modules implementing view callables often have
   ``view`` in their name (or may live in a Python subpackage of your
diff --git a/docs/tutorials/wiki2/installation.rst b/docs/tutorials/wiki2/installation.rst
index e04aea68e..924927cd4 100644
--- a/docs/tutorials/wiki2/installation.rst
+++ b/docs/tutorials/wiki2/installation.rst
@@ -353,22 +353,22 @@ Run the tests
 
 After you've installed the project in development mode as well as the testing
 requirements, you may run the tests for the project. The following commands
-provide options to py.test that specify the module for which its tests shall be
-run, and to run py.test in quiet mode.
+provide options to ``pytest`` that specify the module for which its tests shall be
+run, and to run ``pytest`` in quiet mode.
 
 On Unix
 ^^^^^^^
 
 .. code-block:: bash
 
-    $VENV/bin/py.test -q
+    $VENV/bin/pytest -q
 
 On Windows
 ^^^^^^^^^^
 
 .. code-block:: doscon
 
-    %VENV%\Scripts\py.test -q
+    %VENV%\Scripts\pytest -q
 
 For a successful test run, you should see output that ends like this:
 
@@ -381,8 +381,8 @@ For a successful test run, you should see output that ends like this:
 Expose test coverage information
 --------------------------------
 
-You can run the ``py.test`` command to see test coverage information. This
-runs the tests in the same way that ``py.test`` does, but provides additional
+You can run the ``pytest`` command to see test coverage information. This
+runs the tests in the same way that ``pytest`` does, but provides additional
 :term:`coverage` information, exposing which lines of your project are covered by the
 tests.
 
@@ -394,14 +394,14 @@ On Unix
 
 .. code-block:: bash
 
-    $VENV/bin/py.test --cov --cov-report=term-missing
+    $VENV/bin/pytest --cov --cov-report=term-missing
 
 On Windows
 ^^^^^^^^^^
 
 .. code-block:: doscon
 
-    c:\tutorial> %VENV%\Scripts\py.test --cov --cov-report=term-missing
+    c:\tutorial> %VENV%\Scripts\pytest --cov --cov-report=term-missing
 
 If successful, you will see output something like this:
 
@@ -440,7 +440,7 @@ Our package doesn't quite have 100% test coverage.
 Test and coverage cookiecutter defaults
 ---------------------------------------
 
-Cookiecutters include configuration defaults for ``py.test`` and test coverage.
+Cookiecutters include configuration defaults for ``pytest`` and test coverage.
 These configuration files are ``pytest.ini`` and ``.coveragerc``, located at
 the root of your package. Without these defaults, we would need to specify the
 path to the module on which we want to run tests and coverage.
@@ -450,22 +450,22 @@ On Unix
 
 .. code-block:: bash
 
-    $VENV/bin/py.test --cov=tutorial tutorial/tests.py -q
+    $VENV/bin/pytest --cov=tutorial tutorial/tests.py -q
 
 On Windows
 ^^^^^^^^^^
 
 .. code-block:: doscon
 
-    %VENV%\Scripts\py.test --cov=tutorial tutorial\tests.py -q
+    %VENV%\Scripts\pytest --cov=tutorial tutorial\tests.py -q
 
-py.test follows :ref:`conventions for Python test discovery
+pytest follows :ref:`conventions for Python test discovery
 <pytest:test discovery>`, and the configuration defaults from the cookiecutter
-tell ``py.test`` where to find the module on which we want to run tests and
+tell ``pytest`` where to find the module on which we want to run tests and
 coverage.
 
-.. seealso:: See py.test's documentation for :ref:`pytest:usage` or invoke
-   ``py.test -h`` to see its full set of options.
+.. seealso:: See ``pytest``'s documentation for :ref:`pytest:usage` or invoke
+   ``pytest -h`` to see its full set of options.
 
 
 .. _wiki2-start-the-application:
diff --git a/docs/tutorials/wiki2/tests.rst b/docs/tutorials/wiki2/tests.rst
index a8c35aa51..941a50928 100644
--- a/docs/tutorials/wiki2/tests.rst
+++ b/docs/tutorials/wiki2/tests.rst
@@ -99,14 +99,14 @@ On Unix:
 .. code-block:: bash
 
     rm tutorial.sqlite
-    $VENV/bin/py.test -q
+    $VENV/bin/pytest -q
 
 On Windows:
 
 .. code-block:: doscon
 
     del tutorial.sqlite
-    %VENV%\Scripts\py.test -q
+    %VENV%\Scripts\pytest -q
 
 The expected result should look like the following:
 
diff --git a/docs/typographical-conventions.rst b/docs/typographical-conventions.rst
index 76fdf8ace..7f052cbc8 100644
--- a/docs/typographical-conventions.rst
+++ b/docs/typographical-conventions.rst
@@ -128,7 +128,7 @@ When a command that should be typed on one line is too long to fit on the displa
 
 .. code-block:: bash
 
-    $VENV/bin/py.test tutorial/tests.py --cov-report term-missing \
+    $VENV/bin/pytest tutorial/tests.py --cov-report term-missing \
         --cov=tutorial -q