Merge pull request #7 from stevepiercy/drop-py2

miscellaneous grammar and syntax fixes

4 files changed, 18 insertions, 18 deletions

diff --git a/docs/narr/i18n.rst b/docs/narr/i18n.rst
index 3a4f5af5b..b8cd396c0 100644
--- a/docs/narr/i18n.rst
+++ b/docs/narr/i18n.rst
@@ -62,7 +62,7 @@ This creates a ``str``-like object that is a TranslationString.
 The first argument to :class:`~pyramid.i18n.TranslationString` is the
 ``msgid``; it is required.  It represents the key into the translation mappings
 provided by a particular localization. The ``msgid`` argument must be a string.
-The msgid may optionally contain *replacement markers*.  For instance:
+The ``msgid`` may optionally contain *replacement markers*.  For instance:
 
 .. code-block:: python
     :linenos:
@@ -80,14 +80,14 @@ may be supplied at the same time as the replacement marker itself:
     from pyramid.i18n import TranslationString
     ts = TranslationString('Add ${number}', mapping={'number':1})
 
-Any number of replacement markers can be present in the msgid value, any number
+Any number of replacement markers can be present in the ``msgid`` value, any number
 of times.  Only markers which can be replaced by the values in the *mapping*
 will be replaced at translation time.  The others will not be interpolated and
 will be output literally.
 
 A translation string should also usually carry a *domain*.  The domain
 represents a translation category to disambiguate it from other translations of
-the same msgid, in case they conflict.
+the same ``msgid``, in case they conflict.
 
 .. code-block:: python
     :linenos:
@@ -99,7 +99,7 @@ the same msgid, in case they conflict.
 The above translation string named a domain of ``form``.  A :term:`translator`
 function will often use the domain to locate the right translator file on the
 filesystem which contains translations for a given domain.  In this case, if it
-were trying to translate our msgid to German, it might try to find a
+were trying to translate our ``msgid`` to German, it might try to find a
 translation from a :term:`gettext` file within a :term:`translation directory`
 like this one:
 
diff --git a/docs/narr/traversal.rst b/docs/narr/traversal.rst
index 769d0984c..0282c6096 100644
--- a/docs/narr/traversal.rst
+++ b/docs/narr/traversal.rst
@@ -242,7 +242,7 @@ uses this algorithm to find a :term:`context` resource and a :term:`view name`.
     Conversion from a URL-decoded string into Unicode is attempted using the
     UTF-8 encoding.  If any URL-unquoted path segment in ``PATH_INFO`` is not
     decodeable using the UTF-8 decoding, a :exc:`TypeError` is raised.  A
-    segment will be fully URL-unquoted and UTF8-decoded before it is passed in
+    segment will be fully URL-unquoted and UTF-8-decoded before it is passed in
     to the ``__getitem__`` of any resource during traversal.
 
     Thus a request with a ``PATH_INFO`` variable of ``/a/b/c`` maps to the
diff --git a/docs/narr/urldispatch.rst b/docs/narr/urldispatch.rst
index b9b42a9bd..9372163e8 100644
--- a/docs/narr/urldispatch.rst
+++ b/docs/narr/urldispatch.rst
@@ -165,8 +165,8 @@ The above pattern will match these URLs, generating the following matchdicts:
 
 .. code-block:: text
 
-    foo/1/2        -> {'baz':'1', 'bar':'2'}
-    foo/abc/def    -> {'baz':'abc', 'bar':'def'}
+    foo/1/2        -> {'baz': '1', 'bar': '2'}
+    foo/abc/def    -> {'baz': 'abc', 'bar': 'def'}
 
 It will not match the following patterns however:
 
@@ -184,7 +184,7 @@ instance, if this route pattern was used:
     foo/{name}.html
 
 The literal path ``/foo/biz.html`` will match the above route pattern, and the
-match result will be ``{'name':'biz'}``.  However, the literal path
+match result will be ``{'name': 'biz'}``.  However, the literal path
 ``/foo/biz`` will not match, because it does not contain a literal ``.html`` at
 the end of the segment represented by ``{name}.html`` (it only contains
 ``biz``, not ``biz.html``).
@@ -303,10 +303,10 @@ The above pattern will match these URLs, generating the following matchdicts:
 .. code-block:: text
 
     foo/1/2/           ->
-             {'baz':'1', 'bar':'2', 'fizzle':()}
+             {'baz': '1', 'bar': '2', 'fizzle': ()}
 
     foo/abc/def/a/b/c  ->
-             {'baz':'abc', 'bar':'def', 'fizzle':('a', 'b', 'c')}
+             {'baz': 'abc', 'bar': 'def', 'fizzle': ('a', 'b', 'c')}
 
 Note that when a ``*stararg`` remainder match is matched, the value put into
 the matchdict is turned into a tuple of path segments representing the
@@ -327,7 +327,7 @@ Will generate the following matchdict:
 
 .. code-block:: text
 
-    {'fizzle':('La Pe\xf1a', 'a', 'b', 'c')}
+    {'fizzle': ('La Pe\xf1a', 'a', 'b', 'c')}
 
 By default, the ``*stararg`` will parse the remainder sections into a tuple
 split by segment. Changing the regular expression used to match a marker can
@@ -341,8 +341,8 @@ The above pattern will match these URLs, generating the following matchdicts:
 
 .. code-block:: text
 
-    foo/1/2/           -> {'baz':'1', 'bar':'2', 'fizzle':''}
-    foo/abc/def/a/b/c  -> {'baz':'abc', 'bar':'def', 'fizzle': 'a/b/c'}
+    foo/1/2/           -> {'baz': '1', 'bar': '2', 'fizzle': ''}
+    foo/abc/def/a/b/c  -> {'baz': 'abc', 'bar': 'def', 'fizzle': 'a/b/c'}
 
 This occurs because the default regular expression for a marker is ``[^/]+``
 which will match everything up to the first ``/``, while ``{fizzle:.*}`` will
@@ -513,7 +513,7 @@ When the ``/site/{id}`` route pattern matches during a request, the
 When this route matches, a ``matchdict`` will be generated and attached to the
 request as ``request.matchdict``.  If the specific URL matched is ``/site/1``,
 the ``matchdict`` will be a dictionary with a single key, ``id``; the value
-will be the string ``'1'``, ex.: ``{'id':'1'}``.
+will be the string ``'1'``, ex.: ``{'id': '1'}``.
 
 The ``mypackage.views`` module referred to above might look like so:
 
@@ -581,17 +581,17 @@ forms:
 - When a URL matches the pattern ``/ideas/{idea}``, the view callable
   available at the dotted Python pathname ``mypackage.views.idea_view`` will
   be called.  For the specific URL ``/ideas/1``, the ``matchdict`` generated
-  and attached to the :term:`request` will consist of ``{'idea':'1'}``.
+  and attached to the :term:`request` will consist of ``{'idea': '1'}``.
 
 - When a URL matches the pattern ``/users/{user}``, the view callable
   available at the dotted Python pathname ``mypackage.views.user_view`` will be
   called.  For the specific URL ``/users/1``, the ``matchdict`` generated and
-  attached to the :term:`request` will consist of ``{'user':'1'}``.
+  attached to the :term:`request` will consist of ``{'user': '1'}``.
 
 - When a URL matches the pattern ``/tags/{tag}``, the view callable available
   at the dotted Python pathname ``mypackage.views.tag_view`` will be called.
   For the specific URL ``/tags/1``, the ``matchdict`` generated and attached to
-  the :term:`request` will consist of ``{'tag':'1'}``.
+  the :term:`request` will consist of ``{'tag': '1'}``.
 
 In this example we've again associated each of our routes with a :term:`view
 callable` directly.  In all cases, the request, which will have a ``matchdict``
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 40717c37a..1b4118b85 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -469,7 +469,7 @@ For implicit decoding to work reliably, you should ensure that every form you
 render that posts to a :app:`Pyramid` view explicitly defines a charset
 encoding of UTF-8. This can be done via a response that has a
 ``;charset=UTF-8`` in its ``Content-Type`` header; or, as in the form above,
-with a ``accept-charset`` tag that implies that informs the browser that the
+with an ``accept-charset`` attribute, informing the browser that the
 server expects the form content to be encoded using UTF-8.  This must be done
 explicitly because all known browser clients assume that they should encode
 form data in the same character set implied by the ``Content-Type`` value of