[docs] Use :keyword: ref

CONTRIBUTING.rst

@@ -746,7 +746,7 @@ is following the conventions.
 
         from __future__ import absolute_import
 
-    * If the module uses the with statement and must be compatible
+    * If the module uses the ``with`` statement and must be compatible
       with Python 2.5 (celery is not) then it must also enable that::
 
         from __future__ import with_statement

celery/app/base.py

@@ -278,7 +278,7 @@ class Celery(object):
         """Clean up after the application.
 
         Only necessary for dynamically created apps for which you can
-        use the with statement instead::
+        use the :keyword:`with` statement instead::
 
             with Celery(set_as_current=False) as app:
                 with app.connection_for_write() as conn:
@@ -753,8 +753,8 @@ class Celery(object):
         return self.connection_for_write()
 
     def connection_or_acquire(self, connection=None, pool=True, *_, **__):
-        """For use within a with-statement to get a connection from the pool
-        if one is not already provided.
+        """For use within a :keyword:`with` statement to get a connection
+        from the pool if one is not already provided.
 
         :keyword connection: If not provided, then a connection will be
                              acquired from the connection pool.
@@ -763,8 +763,8 @@ class Celery(object):
     default_connection = connection_or_acquire  # XXX compat
 
     def producer_or_acquire(self, producer=None):
-        """For use within a with-statement to get a producer from the pool
-        if one is not already provided
+        """For use within a :keyword:`with` statement to get a producer
+        from the pool if one is not already provided
 
         :keyword producer: If not provided, then a producer will be
                            acquired from the producer pool.

celery/tests/case.py

@@ -144,7 +144,7 @@ class Mock(mock.Mock):
 
 class _ContextMock(Mock):
     """Dummy class implementing __enter__ and __exit__
-    as the with statement requires these to be implemented
+    as the :keyword:`with` statement requires these to be implemented
     in the class, not just the instance."""
 
     def __enter__(self):

docs/contributing.rst

@@ -774,7 +774,7 @@ is following the conventions.
 
         from __future__ import absolute_import
 
-    * If the module uses the with statement and must be compatible
+    * If the module uses the :keyword:`with` statement and must be compatible
       with Python 2.5 (celery is not) then it must also enable that::
 
         from __future__ import with_statement

docs/faq.rst

@@ -780,7 +780,7 @@ Should I use retry or acks_late?
 to use both.
 
 `Task.retry` is used to retry tasks, notably for expected errors that
-is catchable with the `try:` block. The AMQP transaction is not used
+is catchable with the :keyword:`try` block. The AMQP transaction is not used
 for these errors: **if the task raises an exception it is still acknowledged!**
 
 The `acks_late` setting would be used when you need the task to be

docs/history/changelog-2.2.rst

@@ -599,14 +599,14 @@ Important Notes
     Python 2.4.  Complain to your package maintainers, sysadmins and bosses:
     tell them it's time to move on!
 
-    Apart from wanting to take advantage of with-statements, coroutines,
-    conditional expressions and enhanced try blocks, the code base
-    now contains so many 2.4 related hacks and workarounds it's no longer
-    just a compromise, but a sacrifice.
+    Apart from wanting to take advantage of :keyword:`with` statements,
+    coroutines, conditional expressions and enhanced :keyword:`try` blocks,
+    the code base now contains so many 2.4 related hacks and workarounds
+    it's no longer just a compromise, but a sacrifice.
 
     If it really isn't your choice, and you don't have the option to upgrade
     to a newer version of Python, you can just continue to use Celery 2.2.
-    Important fixes can be backported for as long as there is interest.
+    Important fixes can be back ported for as long as there is interest.
 
 * worker: Now supports Autoscaling of child worker processes.
 

docs/history/changelog-3.0.rst

@@ -1106,7 +1106,7 @@ If you're looking for versions prior to 3.0.x you should go to :ref:`history`.
 
 - Unit test suite now passes for PyPy 1.9.
 
-- App instances now supports the with statement.
+- App instances now supports the :keyword:`with` statement.
 
     This calls the new :meth:`@close` method at exit, which
     cleans up after the app like closing pool connections.

docs/history/changelog-3.1.rst

@@ -461,7 +461,7 @@ new in Celery 3.1.
   before importing any task modules (Django 1.7 compatibility, Issue #2227)
 
 - **Results**: ``result.get()`` was misbehaving by calling
-  ``backend.get_task_meta`` in a finally call leading to
+  ``backend.get_task_meta`` in a :keyword:`finally` call leading to
   AMQP result backend queues not being properly cleaned up (Issue #2245).
 
 .. _version-3.1.14:
@@ -1452,8 +1452,8 @@ Fixes
 - Worker now properly responds to ``inspect stats`` commands
   even if received before startup is complete (Issue #1659).
 
-- :signal:`task_postrun` is now sent within a finally block, to make
-  sure the signal is always sent.
+- :signal:`task_postrun` is now sent within a :keyword:`finally` block,
+  to make sure the signal is always sent.
 
 - Beat: Fixed syntax error in string formatting.
 

docs/userguide/signals.rst

@@ -483,8 +483,9 @@ worker_process_shutdown
 Dispatched in all pool child processes just before they exit.
 
 Note: There is no guarantee that this signal will be dispatched,
-similarly to finally blocks it's impossible to guarantee that handlers
-will be called at shutdown, and if called it may be interrupted during.
+similarly to :keyword:`finally` blocks it's impossible to guarantee that
+handlers will be called at shutdown, and if called it may be
+interrupted during.
 
 Provides arguments:
 

docs/userguide/tasks.rst

@@ -541,7 +541,8 @@ Autoretrying
 .. versionadded:: 4.0
 
 Sometimes you may want to retry a task on particular exception. To do so,
-you should wrap a task body with `try-except` statement, for example:
+you should wrap a task body with :keyword:`try` ... :keyword:`except`
+statement, for example:
 
 .. code-block:: python