make 'python' default highlighting language, and set 'lineno' globally

Also fix 2 cases where INI configs where highlighted as 'python' code

auth/basic.rst

@@ -1,10 +1,7 @@
 Basic Authentication Policy
 %%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-Here's an implementation of an HTTP basic auth Pyramid authentication policy:
-
-.. code-block:: python
-   :linenos:
+Here's an implementation of an HTTP basic auth Pyramid authentication policy::
 
    import binascii
 
@@ -93,10 +90,7 @@ Here's an implementation of an HTTP basic auth Pyramid authentication policy:
            head = WWW_AUTHENTICATE.tuples('Basic realm="%s"' % self.realm)
            return head
 
-Use it something like:
-
-.. code-block:: python
-   :linenos:
+Use it something like::
 
    def mycheck(credentials, request):
        pwd_ok = my_password_check(credentials['login'], credentials['password'])

auth/custom.rst

@@ -5,10 +5,7 @@ Here is an example of a custom AuthenticationPolicy, based off of
 the native ``AuthTktAuthenticationPolicy``, but with added groups support.
 This example implies you have a ``user`` attribute on your request
 (see :ref:`user object`) and that the ``user`` should have a
-``groups`` relation on it:
-
-.. code-block:: python
-   :linenos:
+``groups`` relation on it::
 
    from pyramid.authentication import AuthTktCookieHelper
    from pyramid.security import Everyone, Authenticated

auth/user_object.rst

@@ -22,10 +22,7 @@ This allows you to specify a
 callable that will be available on the request object, but will not actually
 execute the function until accessed. The result of this function can also
 be cached per-request, to eliminate the overhead of running the function
-multiple times (this is done by setting ``reify=True``.
-
-.. code-block:: python
-   :linenos:
+multiple times (this is done by setting ``reify=True``::
 
    from pyramid.security import unauthenticated_userid
 
@@ -55,10 +52,7 @@ done (as would be if you used a ``NewRequest`` subscriber).
 After doing such a thing, if your user object has a ``groups`` attribute,
 which returns a list of groups that have ``name`` attributes, you can use the
 following as a ``callback`` (aka ``groupfinder``) argument to most builtin
-authentication policies.  For example:
-
-.. code-block:: python
-   :linenos:
+authentication policies.  For example::
 
    from pyramid.authentication import AuthTktAuthenticationPolicy
 
@@ -88,10 +82,7 @@ via :meth:`~pyramid.config.Configurator.set_request_factory`. This works
 in the same way, but each application can only have one request factory
 and so it is not very extensible for arbitrary properties.
 
-The code for this method is below:
-
-.. code-block:: python
-   :linenos:
+The code for this method is below::
 
     from pyramid.decorator import reify
     from pyramid.request import Request

auth/wiki2_auth.rst

@@ -190,9 +190,7 @@ Cycle 2:
    ``login_url`` is ``http://localhost:6543/login``, and the
    value of ``referrer`` is ``'/'``, and ``came_from`` is
    ``http://localhost:6543/FrontPage/edit_page`` when this block
-   is executed:
-
-   .. code-block:: python
+   is executed::
 
         if USERS.get(login) == password:
             headers = remember(request, login)

conf.py

@@ -257,3 +257,8 @@ def app_role(role, rawtext, text, lineno, inliner, options={}, content=[]):
 def setup(app):
     app.add_role('app', app_role)
 
+# Avoid the need to specify linenos
+rst_prolog = '''
+.. highlight:: python
+   :linenothreshold: 5
+'''

configuration/django_settings.rst

@@ -10,19 +10,14 @@ Django's ``settings.py``, you can do something similar in Pyramid.
 
 - Add values to it at its top level.
 
-For example:
-
-.. code-block:: python
+For example::
 
   # settings.py
-
   import pytz
 
   timezone = pytz('US/Eastern')
 
-Then simply import the module into your application:
-
-.. code-block:: python
+Then simply import the module into your application::
 
   from myapp import settings
 

configuration/whirlwind_tour.rst

@@ -12,9 +12,7 @@ developer adds configuration by calling configuration *directives*.  For
 example, ``config.add_route()`` is a configuration directive.  A particular
 *use* of ``config.add_route()`` is a configuration *statement*.  In the below
 code block, the execution of the ``add_route()`` directive is a configuration
-statement.  Configuration statements change pending configuration state:
-
-.. code-block:: python
+statement.  Configuration statements change pending configuration state::
 
    config = pyramid.config.Configurator()
    config.add_route('home', '/')
@@ -70,9 +68,7 @@ Here are a few core concepts related to Pyramid startup configuration:
    is always more explicit than that.
 
 Let's see some of those concepts in action.  Here's one of the simplest
-possible Pyramid applications:
-
-.. code-block:: python
+possible Pyramid applications::
 
    # app.py
 
@@ -98,9 +94,7 @@ exciting.
 What happens when we reorder our configuration statements?  We'll change the
 relative ordering of ``add_view()`` and ``add_route()`` configuration
 statements.  Instead of adding a route, then a view, we'll add a view then a
-route:
-
-.. code-block:: python
+route::
 
    # app.py
 
@@ -142,9 +136,7 @@ Sanity Checks
 
 We can see this sanity-checking feature in action in a failure case.  Let's
 change our application, commenting out our call to ``config.add_route()``
-temporarily within ``app.py``:
-
-.. code-block:: python
+temporarily within ``app.py``::
 
    # app.py
 
@@ -191,9 +183,7 @@ Configuration Conflicts
 -----------------------
 
 Let's change our application once again.  We'll undo our last change, and add
-a configuration statement that attempts to add another view:
-
-.. code-block:: python
+a configuration statement that attempts to add another view::
 
    # app.py
 
@@ -269,9 +259,7 @@ Resolving Conflicts
 Obviously it's necessary to be able to resolve configuration conflicts.
 Sometimes these conflicts are done by mistake, so they're easy to resolve.
 You just change the code so that the conflict is no longer present.  We can
-do that pretty easily:
-
-.. code-block:: python
+do that pretty easily::
 
    # app.py
 
@@ -305,9 +293,7 @@ There's an alternative way to resolve conflicts that doesn't change the
 semantics of the code as much.  You can issue a ``config.commit()`` statement
 to flush pending configuration actions before issuing more.  To see this in
 action, let's change our application back to the way it was before we added
-the ``request_param`` predicate to our second ``add_view`` statement:
-
-.. code-block:: python
+the ``request_param`` predicate to our second ``add_view`` statement::
 
    # app.py
 
@@ -333,9 +319,7 @@ the ``request_param`` predicate to our second ``add_view`` statement:
 If we try to run this application as-is, we'll wind up with a configuration
 conflict error.  We can actually sort of brute-force our way around that by
 adding a manual call to ``commit`` between the two ``add_view`` statements
-which conflict:
-
-.. code-block:: python
+which conflict::
 
    # app.py
 
@@ -381,9 +365,7 @@ Including Configuration from Other Modules
 Now that we have played around a bit with configuration that exists all in
 the same module, let's add some code to ``app.py`` that causes configuration
 that lives in another module to be *included*.  We do that by adding a call
-to ``config.include()`` within ``app.py``:
-
-.. code-block:: python
+to ``config.include()`` within ``app.py``::
 
    # app.py
 
@@ -423,9 +405,7 @@ If we try to run the application now, we'll receive a traceback::
 
 That's exactly as we expected, because we attempted to *include* a module
 that doesn't yet exist.  Let's add a module named ``another.py`` right next
-to our ``app.py`` module:
-
-.. code-block:: python
+to our ``app.py`` module::
 
    # another.py
 
@@ -466,9 +446,7 @@ The :func:`includeme` Convention
 
 Now, let's change our ``app.py`` slightly.  We'll change the
 ``config.include()`` line in ``app.py`` to include a slightly different
-name:
-
-.. code-block:: python
+name::
 
    # app.py
 
@@ -489,9 +467,7 @@ name:
        server.serve_forever()
 
 And we'll edit ``another.py``, changing the name of the
-``moreconfiguration`` function to ``includeme``:
-
-.. code-block:: python
+``moreconfiguration`` function to ``includeme``::
 
    # another.py
 
@@ -520,9 +496,7 @@ Nested Includes
 ---------------
 
 Something which is included can also do including.  Let's add a file named
-``yetanother.py`` next to app.py:
-
-.. code-block:: python
+``yetanother.py`` next to app.py::
 
    # yetanother.py
 
@@ -535,9 +509,7 @@ Something which is included can also do including.  Let's add a file named
        config.add_route('whoa', '/whoa')
        config.add_view(whoa, route_name='whoa')
 
-And let's change our ``another.py`` file to include it:
-
-.. code-block:: python
+And let's change our ``another.py`` file to include it::
 
    # another.py
 
@@ -569,9 +541,7 @@ configuration before a conflict occurs.
 
 Let's change our ``another.py`` to contain a ``hi_world`` view function, and
 we'll change its ``includeme`` to add that view that should answer when ``/``
-is visited:
-
-.. code-block:: python
+is visited::
 
    # another.py
 
@@ -632,9 +602,7 @@ UI somewhere).  Let's further pretend you'd like to do this by allowing
 people to call a ``set_site_name`` directive on the Configurator.  This is a
 bit of a contrived example, because it would probably be a bit easier in this
 particular case just to use a deployment setting, but humor me for the
-purpose of this example.  Let's change our app.py to look like this:
-
-.. code-block:: python
+purpose of this example.  Let's change our app.py to look like this::
 
    # app.py
 
@@ -656,9 +624,7 @@ purpose of this example.  Let's change our app.py to look like this:
        server = make_server('0.0.0.0', 8080, app)
        server.serve_forever()
 
-And change our ``another.py`` to look like this:
-
-.. code-block:: python
+And change our ``another.py`` to look like this::
 
    # another.py
 
@@ -688,9 +654,7 @@ This is not a Pyramid built-in directive.  It was added as the result of the
 call to ``config.add_directive`` in ``another.includeme``.  We added a
 function that uses the ``config.action`` method to register a discriminator
 and a callback for a *custom* directive.  Let's change ``app.py`` again,
-adding a second call to ``set_site_name``:
-
-.. code-block:: python
+adding a second call to ``set_site_name``::
 
    # app.py
 
@@ -738,9 +702,7 @@ detection.  When we tried to set the site name twice, Pyramid detected a
 conflict and told us.  Just like built-in directives, Pyramid custom
 directives will also participate in automatic conflict resolution.  Let's see
 that in action by moving our first call to ``set_site_name`` into another
-included function.  As a result, our ``app.py`` will look like this:
-
-.. code-block:: python
+included function.  As a result, our ``app.py`` will look like this::
 
    # app.py
 

database/catalog.rst

@@ -25,10 +25,7 @@ want the application to be based on :term:`traversal`.
       $ easy_install repoze.catalog
 
 #. Change your ZODB application's ``models.py`` file to look like the
-   below:
-
-   .. code-block:: python
-      :linenos:
+   below::
 
        from repoze.folder import Folder
        from repoze.catalog.catalog import Catalog

database/couchdb.rst

@@ -19,10 +19,7 @@ CouchDB URI and a database name (the CouchDB database name, can be anything).
     couchdb.db = mydb
 
 Then in your ``__init__.py``, set things up such that the database is
-attached to each new request:
-
-.. code-block:: python
-   :linenos:
+attached to each new request::
 
     from pyramid.config import Configurator
     from couchdbkit import *
@@ -51,10 +48,7 @@ attached to each new request:
    You can use ``Configurator.set_request_property`` for Pyramid 1.3.
 
 At this point, in view code, you can use ``request.db`` as the CouchDB database
-connection.  For example:
-
-.. code-block:: python
-   :linenos:
+connection.  For example::
 
     from pyramid.view import view_config
 
@@ -81,10 +75,7 @@ First let's create a view for our page data in CouchDB. We will use the
 ApplicationCreated event and make sure our view containing our page data.
 For more information on views in CouchDB see
 `Introduction to CouchDB views <http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views>`_.
-In __init__.py:
-
-.. code-block:: python
-   :linenos:
+In __init__.py::
 
     from pyramid.events import ApplicationCreated
 
@@ -119,10 +110,7 @@ CouchDB Documents
 -----------------
 
 Now we can let's add some data to a document for our home page in a CouchDB
-document in our view code if it doesn't exist:
-
-.. code-block:: python
-    :linenos:
+document in our view code if it doesn't exist::
 
     import datetime