New Sphinx xref abbrevitations

Changelog

@@ -347,7 +347,7 @@ News
 * Now handles missing fields in task messages as documented in the message
   format documentation.
 
-    * Missing required field throws :exc:`InvalidTaskError`
+    * Missing required field throws :exc:`~@InvalidTaskError`
     * Missing args/kwargs is assumed empty.
 
     Contributed by Chris Chamberlin.
@@ -1905,7 +1905,7 @@ Fixes
 * celeryd: Now sends the `task-retried` event for retried tasks.
 
 * celeryd: Now honors ignore result for
-  :exc:`~celery.exceptions.WorkerLostError` and timeout errors.
+  :exc:`~@WorkerLostError` and timeout errors.
 
 * celerybeat: Fixed :exc:`UnboundLocalError` in celerybeat logging
   when using logging setup signals.
@@ -2212,7 +2212,7 @@ News
         ...                  expires=datetime.now() + timedelta(days=1)
 
     When a worker receives a task that has been expired it will be
-    marked as revoked (:exc:`celery.exceptions.TaskRevokedError`).
+    marked as revoked (:exc:`~@TaskRevokedError`).
 
 * Changed the way logging is configured.
 
@@ -2324,7 +2324,7 @@ News
   `remaining_estimate` (*Optimization*).
 
 * celeryd:  Store :state:`FAILURE` result if the
-   :exc:`~celery.exceptions.WorkerLostError` exception occurs (worker process
+   :exc:`~@WorkerLostError` exception occurs (worker process
    disappeared).
 
 * celeryd: Store :state:`FAILURE` result if one of the `*TimeLimitExceeded`
@@ -3061,7 +3061,7 @@ Backward incompatible changes
 * Default (python) loader now prints warning on missing `celeryconfig.py`
   instead of raising :exc:`ImportError`.
 
-    celeryd raises :exc:`~celery.exceptions.ImproperlyConfigured` if the configuration
+    celeryd raises :exc:`~@ImproperlyConfigured` if the configuration
     is not set up. This makes it possible to use `--help` etc., without having a
     working configuration.
 
@@ -3281,7 +3281,7 @@ News
 
     * :setting:`CELERYD_SOFT_TASK_TIME_LIMIT`
 
-        Soft time limit. The :exc:`celery.exceptions.SoftTimeLimitExceeded`
+        Soft time limit. The :exc:`~@SoftTimeLimitExceeded`
         exception will be raised when this is exceeded.  The task can catch
         this to e.g. clean up before the hard time limit comes.
 
@@ -3384,7 +3384,7 @@ News
     the process is terminated and replaced by a new one.
 
 * Revoked tasks now marked with state :state:`REVOKED`, and `result.get()`
-  will now raise :exc:`~celery.exceptions.TaskRevokedError`.
+  will now raise :exc:`~@TaskRevokedError`.
 
 * :func:`celery.task.control.ping` now works as expected.
 
@@ -4407,7 +4407,7 @@ Changes
 * The services now sets informative process names (as shown in `ps`
   listings) if the :mod:`setproctitle` module is installed.
 
-* :exc:`celery.exceptions.NotRegistered` now inherits from :exc:`KeyError`,
+* :exc:`~@NotRegistered` now inherits from :exc:`KeyError`,
   and `TaskRegistry.__getitem__`+`pop` raises `NotRegistered` instead
 
 * You can set the loader via the :envvar:`CELERY_LOADER` environment variable.

celery/__compat__.py

@@ -28,6 +28,8 @@ def getappattr(path):
     e.g. getappattr("amqp.get_task_consumer")``."""
     from celery import current_app
     return reduce(lambda a, b: getattr(a, b), [current_app] + path)
+
+
 def _compat_task_decorator(*args, **kwargs):
     from celery import current_app
     kwargs.setdefault("accept_magic_kwargs", True)
@@ -122,17 +124,6 @@ class MagicModule(ModuleType):
         return list(set(self.__all__) + DEFAULT_ATTRS)
 
 
-def get_compat_module(pkg, name):
-
-    def prepare(attr):
-        if isinstance(attr, basestring):
-            return Proxy(getappattr, (attr.split('.'), ))
-        return attr
-
-    return create_module(name, COMPAT_MODULES[pkg.__name__][name],
-                         pkg=pkg, prepare_attr=prepare)
-
-
 def create_module(name, attrs, cls_attrs=None, pkg=None,
         bases=(MagicModule, ), prepare_attr=None):
     fqdn = '.'.join([pkg.__name__, name]) if pkg else name
@@ -145,12 +136,6 @@ def create_module(name, attrs, cls_attrs=None, pkg=None,
     return module
 
 
-def get_origins(defs):
-    origins = {}
-    for module, items in defs.iteritems():
-        origins.update(dict((item, module) for item in items))
-    return origins
-
 def recreate_module(name, compat_modules=(), by_module={}, direct={}, **attrs):
     old_module = sys.modules[name]
     origins = get_origins(by_module)
@@ -165,3 +150,21 @@ def recreate_module(name, compat_modules=(), by_module={}, direct={}, **attrs):
     new_module.__dict__.update(dict((mod, get_compat_module(new_module, mod))
                                      for mod in compat_modules))
     return old_module, new_module
+
+
+def get_compat_module(pkg, name):
+
+    def prepare(attr):
+        if isinstance(attr, basestring):
+            return Proxy(getappattr, (attr.split('.'), ))
+        return attr
+
+    return create_module(name, COMPAT_MODULES[pkg.__name__][name],
+                         pkg=pkg, prepare_attr=prepare)
+
+
+def get_origins(defs):
+    origins = {}
+    for module, items in defs.iteritems():
+        origins.update(dict((item, module) for item in items))
+    return origins

celery/__init__.py

@@ -14,22 +14,15 @@ __docformat__ = "restructuredtext"
 
 # -eof meta-
 
-import sys
-
-if sys.version_info < (2, 5):
-    raise Exception(
-        "Python 2.4 is not supported by this version. "
-        "Please use Celery versions 2.1.x or earlier.")
-
 # Lazy loading
 from .__compat__ import recreate_module
 
 
 old_module, new_module = recreate_module(__name__,
     by_module={
-        "celery.app": ["Celery", "bugreport"],
-        "celery.app.state": ["current_app", "current_task"],
-        "celery.task.sets": ["chain", "group", "subtask"],
+        "celery.app":         ["Celery", "bugreport"],
+        "celery.app.state":   ["current_app", "current_task"],
+        "celery.task.sets":   ["chain", "group", "subtask"],
         "celery.task.chords": ["chord"],
     },
     direct={"task": "celery.task"},

celery/task/__init__.py

@@ -24,9 +24,9 @@ class module(MagicModule):
 
 old_module, new_module = recreate_module(__name__,
     by_module={
-        "celery.task.base": ["BaseTask", "Task", "PeriodicTask",
-                             "task", "periodic_task"],
-        "celery.task.sets": ["chain", "group", "TaskSet", "subtask"],
+        "celery.task.base":   ["BaseTask", "Task", "PeriodicTask",
+                               "task", "periodic_task"],
+        "celery.task.sets":   ["chain", "group", "TaskSet", "subtask"],
         "celery.task.chords": ["chord"],
     },
     base=module,

docs/_ext/celerydocs.py

@@ -1,4 +1,89 @@
+from docutils import nodes
+
+from sphinx.environment import NoUri
+from sphinx.util.nodes import make_refnode
+
+ABBR = {
+    "": "celery.app.base.Celery",
+    "amqp": "celery.app.amqp.AMQP",
+    "backend": "celery.backends.base.BaseBackend",
+    "control": "celery.app.control.Control",
+    "events": "celery.events.Events",
+    "loader": "celery.app.loaders.base.BaseLoader",
+    "log": "celery.app.log.Logging",
+    "pool": "kombu.connection.ConnectionPool",
+    "tasks": "celery.app.registry.Registry",
+
+    "AsyncResult": "celery.result.AsyncResult",
+    "TaskSetResult": "celery.result.TaskSetResult",
+    "Worker": "celery.apps.worker.Worker",
+    "WorkController": "celery.worker.WorkController",
+    "Beat": "celery.apps.beat.Beat",
+    "Task": "celery.app.task.BaseTask",
+}
+
+ABBR_EMPTY = {
+    "exc": "celery.exceptions",
+}
+DEFAULT_EMPTY = "celery.app.base.Celery"
+
+
+def shorten(S, base):
+    if S.startswith('@-'):
+        return S[2:]
+    elif S.startswith('@'):
+        print("S: %r BASE: %r" % (S, base))
+        return '.'.join([base, S[1:]])
+    return S
+
+
+def resolve(S, type):
+    X = S
+    if S.startswith('@'):
+        S = S.lstrip('@-')
+        try:
+            pre, rest = S.split('.', 1)
+        except ValueError:
+            pre, rest = '', S
+        return '.'.join([ABBR[pre] if pre
+                                   else ABBR_EMPTY.get(type, DEFAULT_EMPTY),
+                         rest])
+
+
+def pkg_of(module_fqdn):
+    return module_fqdn.split('.', 1)[0]
+
+
+def modify_textnode(T, newtarget, node):
+    src = node.children[0].rawsource
+    return nodes.Text(
+        T.lstrip('@') if '~' in src else shorten(T, pkg_of(newtarget)),
+        src
+    )
+
+
+def maybe_resolve_abbreviations(app, env, node, contnode):
+    domainname = node.get('refdomain')
+    target = node["reftarget"]
+    type = node["reftype"]
+    if target.startswith('@'):
+        newtarget = node["reftarget"] = resolve(target, type)
+        # shorten text if '~' is not enabled.
+        if len(contnode) and isinstance(contnode[0], nodes.Text):
+                contnode[0] = modify_textnode(target, newtarget, node)
+        if domainname:
+            try:
+                domain = env.domains[node.get("refdomain")]
+            except KeyError:
+                raise NoUri
+            return domain.resolve_xref(env, node["refdoc"], app.builder,
+                                       type, newtarget,
+                                       node, contnode)
+
+
 def setup(app):
+    app.connect('missing-reference', maybe_resolve_abbreviations)
+
     app.add_crossref_type(
         directivename="setting",
         rolename="setting",

docs/configuration.rst

@@ -1089,7 +1089,7 @@ CELERYD_TASK_SOFT_TIME_LIMIT
 
 Task soft time limit in seconds.
 
-The :exc:`~celery.exceptions.SoftTimeLimitExceeded` exception will be
+The :exc:`~@SoftTimeLimitExceeded` exception will be
 raised when this is exceeded.  The task can catch this to
 e.g. clean up before the hard time limit comes.
 

docs/internals/reference/celery.execute.trace.rst → docs/internals/reference/celery.task.trace.rst

@@ -1,11 +1,11 @@
 ==========================================
- celery.execute.trace
+ celery.task.trace
 ==========================================
 
 .. contents::
     :local:
-.. currentmodule:: celery.execute.trace
+.. currentmodule:: celery.task.trace
 
-.. automodule:: celery.execute.trace
+.. automodule:: celery.task.trace
     :members:
     :undoc-members:

docs/internals/reference/index.rst

@@ -37,7 +37,7 @@
     celery.backends.redis
     celery.backends.cassandra
     celery.backends.tyrant
-    celery.execute.trace
+    celery.task.trace
     celery.app.abstract
     celery.app.annotations
     celery.app.state

docs/userguide/executing.rst

@@ -13,17 +13,17 @@
 Basics
 ======
 
-Executing a task is done with :meth:`~celery.task.Base.Task.apply_async`,
-and the shortcut: :meth:`~celery.task.Base.Task.delay`.
+Executing a task is done with :meth:`~@Task.apply_async`,
+or its shortcut: :meth:`~@Task.delay`.
 
-`delay` is simple and convenient, as it looks like calling a regular
+:meth:`~@Task.delay` is simple and convenient, as it looks like calling a regular
 function:
 
 .. code-block:: python
 
     Task.delay(arg1, arg2, kwarg1="x", kwarg2="y")
 
-The same using `apply_async` is written like this:
+The same using :meth:`~@Task.apply_async` is written like this:
 
 .. code-block:: python
 
@@ -32,7 +32,7 @@ The same using `apply_async` is written like this:
 
 While `delay` is convenient, it doesn't give you as much control as using
 `apply_async`.  With `apply_async` you can override the execution options
-available as attributes on the `Task` class (see :ref:`task-options`).
+available as attributes on the :class:`~@Task` class (see :ref:`task-options`).
 In addition you can set countdown/eta, task expiry, provide a custom broker
 connection and more.
 
@@ -48,7 +48,7 @@ called `add`, returning the sum of two positional arguments:
 .. note::
 
     You can also execute a task by name using
-    :func:`~celery.execute.send_task`, if you don't have access to the
+    :func:`~@send_task`, if you don't have access to the
     task class::
 
         >>> from celery.execute import send_task
@@ -111,7 +111,7 @@ either as seconds after task publish, or a specific date and time using
 
 
 When a worker receives an expired task it will mark
-the task as :state:`REVOKED` (:exc:`~celery.exceptions.TaskRevokedError`).
+the task as :state:`REVOKED` (:exc:`~@TaskRevokedError`).
 
 .. _executing-serializers:
 

docs/userguide/tasks.rst

@@ -7,19 +7,15 @@
 .. contents::
     :local:
 
-
-This guide gives an overview of how tasks are defined. For a complete
-listing of task attributes and methods, please see the
-:class:`API reference <celery.task.base.BaseTask>`.
-
 .. _task-basics:
 
 Basics
 ======
 
 A task is a class that encapsulates a function and its execution options.
-Given a function create_user`, that takes two arguments: `username` and
-`password`, you can create a task like this:
+Given a function ``create_user`` taking two arguments: `username` and
+`password`, you can easily create a task from any function by using
+the task decorator:
 
 .. code-block:: python
 
@@ -29,8 +25,7 @@ Given a function create_user`, that takes two arguments: `username` and
     def create_user(username, password):
         User.objects.create(username=username, password=password)
 
-
-Task options are added as arguments to `task`:
+Task options can be specified as arguments to the decorator:
 
 .. code-block:: python
 
@@ -43,8 +38,8 @@ Task options are added as arguments to `task`:
 Context
 =======
 
-`task.request` contains information and state related
-the currently executing task, and must always contain the following
+:attr:`@-Task.request` contains information and state related
+the currently executing task, and always contains the following
 attributes:
 
 :id: The unique id of the executing task.
@@ -69,17 +64,14 @@ attributes:
 
 :delivery_info: Additional message delivery information. This is a mapping
                 containing the exchange and routing key used to deliver this
-                task.  Used by e.g. :meth:`~celery.task.base.BaseTask.retry`
+                task.  Used by e.g. :meth:`~@Task.retry`
                 to resend the task to the same destination queue.
 
-  **NOTE** As some messaging backends don't have advanced routing
-  capabilities, you can't trust the availability of keys in this mapping.
-
 
 Example Usage
 -------------
 
-::
+.. code-block:: python
 
     @celery.task
     def add(x, y):
@@ -91,8 +83,9 @@ Example Usage
 Logging
 =======
 
-You can use the workers logger to add diagnostic output to
-the worker log:
+The worker will automatically set up logging for you, or you can
+configure logging manually.  Every task will also have a dedicated
+logger that can be used freely to emit logs from your tasks.
 
 .. code-block:: python
 
@@ -102,20 +95,21 @@ the worker log:
         logger.info("Adding %s + %s" % (x, y))
         return x + y
 
-There are several logging levels available, and the workers `loglevel`
-setting decides whether or not they will be written to the log file.
+:meth:`@-Task.get_logger` returns a standard Python logger instance,
+for which documentation can be found in the standard library's :mod:`logging`
+module.
 
-Of course, you can also simply use `print` as anything written to standard
-out/-err will be written to the log file as well.
+You can also simply use :func:`print`, as anything written to standard
+out/-err will be redirected to a logger by default (see
+:setting:`CELERY_REDIRECT_STDOUTS`).
 
 .. _task-retry:
 
 Retrying a task if something fails
 ==================================
 
-Simply use :meth:`~celery.task.base.BaseTask.retry` to re-send the task.
-It will do the right thing, and respect the
-:attr:`~celery.task.base.BaseTask.max_retries` attribute:
+:meth:`@-Task.retry` can be used to re-send the task, for example in the event
+of temporary failure.
 
 .. code-block:: python
 
@@ -128,16 +122,16 @@ It will do the right thing, and respect the
             send_twitter_status.retry(exc=exc)
 
 Here we used the `exc` argument to pass the current exception to
-:meth:`~celery.task.base.BaseTask.retry`. At each step of the retry this exception
+:meth:`@-Task.retry`. At each step of the retry this exception
 is available as the tombstone (result) of the task. When
-:attr:`~celery.task.base.BaseTask.max_retries` has been exceeded this is the
+:attr:`@-Task.max_retries` has been exceeded this is the
 exception raised.  However, if an `exc` argument is not provided the
-:exc:`~celery.exceptions.RetryTaskError` exception is raised instead.
+:exc:`~@RetryTaskError` exception is raised instead.
 
 .. note::
 
-    The :meth:`retry` call will raise an exception so any code after the retry
-    will not be reached.  This is the :exc:`celery.exceptions.RetryTaskError`
+    The :meth:`~@Task.retry` call will raise an exception so any code after the retry
+    will not be reached.  This is the :exc:`~@RetryTaskError`
     exception, it is not handled as an error but rather as a semi-predicate
     to signify to the worker that the task is to be retried.
 
@@ -151,12 +145,12 @@ Using a custom retry delay
 
 When a task is to be retried, it will wait for a given amount of time
 before doing so. The default delay is in the
-:attr:`~celery.task.base.BaseTask.default_retry_delay`
+:attr:`~@Task.default_retry_delay`
 attribute on the task. By default this is set to 3 minutes. Note that the
 unit for setting the delay is in seconds (int or float).
 
-You can also provide the `countdown` argument to
-:meth:`~celery.task.base.BaseTask.retry` to override this default.
+You can also provide the `countdown` argument to :meth:`~@Task.retry` to
+override this default.
 
 .. code-block:: python
 
@@ -186,7 +180,7 @@ General
     automatically generated using the module and class name.  See
     :ref:`task-names`.
 
-.. attribute Task.request
+.. attribute:: Task.request
 
     If the task is being executed this will contain information
     about the current request.  Thread local storage is used.
@@ -201,9 +195,9 @@ General
 .. attribute:: Task.max_retries
 
     The maximum number of attempted retries before giving up.
-    If this exceeds the :exc:`~celery.exceptions.MaxRetriesExceeded`
-    an exception will be raised.  *NOTE:* You have to :meth:`retry`
-    manually, it's not something that happens automatically.
+    If the number of retries exceeds this value a :exc:`~@MaxRetriesExceeded`
+    exception will be raised.  *NOTE:* You have to call :meth:`~@Task.retry`
+    manually, as it will not automatically retry on exception..
 
 .. attribute:: Task.default_retry_delay
 
@@ -304,7 +298,7 @@ General
 
 .. seealso::
 
-    The API reference for :class:`~celery.task.base.BaseTask`.
+    The API reference for :class:`~@Task`.
 
 .. _task-message-options:
 
@@ -349,7 +343,7 @@ Message and routing options
     The message priority. A number from 0 to 9, where 0 is the
     highest priority.
 
-    Not supported by RabbitMQ.
+    Only supported by Beanstalk.
 
 .. seealso::
 
@@ -387,16 +381,19 @@ another module:
     >>> def add(x, y):
     ...     return x + y
 
+
+You can tell the name of the task by investigating its name attribute::
+
     >>> add.name
     'tasks.add'
 
 
-Which is exactly the name that is automatically generated for this
+Which is exactly the name automatically generated for this
 task if the module name is "tasks.py":
 
 .. code-block:: python
 
-    >>> @celery.task()
+    >>> @celery.task
     >>> def add(x, y):
     ...     return x + y
 
@@ -413,7 +410,7 @@ so if you're using relative imports you should set the name explicitly.
 
 For example if the client imports the module "myapp.tasks" as ".tasks", and
 the worker imports the module as "myapp.tasks", the generated names won't match
-and an :exc:`~celery.exceptions.NotRegistered` error will be raised by the worker.
+and an :exc:`~@NotRegistered` error will be raised by the worker.
 
 This is also the case if using Django and using `project.myapp`::
 
@@ -545,8 +542,7 @@ web applications with a database already in place, but it also comes with
 limitations.
 
 * Polling the database for new states is expensive, and so you should
-  increase the polling intervals of operations such as `result.wait()`, and
-  `tasksetresult.join()`
+  increase the polling intervals of operations such as `result.get()`.
 
 * Some databases use a default transaction isolation level that
   is not suitable for polling tables for changes.
@@ -576,7 +572,7 @@ STARTED
 ~~~~~~~
 
 Task has been started.
-Not reported by default, to enable please see :attr:`Task.track_started`.
+Not reported by default, to enable please see :attr:`@Task.track_started`.
 
 :metadata: `pid` and `hostname` of the worker process executing
            the task.
@@ -635,8 +631,7 @@ The name of the state is usually an uppercase string.  As an example
 you could have a look at :mod:`abortable tasks <~celery.contrib.abortable>`
 which defines its own custom :state:`ABORTED` state.
 
-Use :meth:`Task.update_state <celery.task.base.BaseTask.update_state>` to
-update a task's state::
+Use :meth:`~@Task.update_state` to update a task's state::
 
     @celery.task
     def upload_files(filenames):
@@ -713,10 +708,10 @@ you have to pass them as regular args:
 Creating custom task classes
 ============================
 
-All tasks inherit from the :class:`celery.task.Task` class.
-The task's body is its :meth:`run` method.
+All tasks inherit from the :class:`@Task` class.
+The :meth:`~@Task.run` method becomes the task body.
 
-The following code,
+As an example, the following code,
 
 .. code-block:: python
 
@@ -801,7 +796,7 @@ Handlers
 
 .. method:: execute(self, request, pool, loglevel, logfile, \*\*kw):
 
-    :param request: A :class:`~celery.worker.job.TaskRequest`.
+    :param request: A :class:`~celery.worker.job.Request`.
     :param pool: The task pool.
     :param loglevel: Current loglevel.
     :param logfile: Name of the currently used logfile.
@@ -843,7 +838,7 @@ Handlers
 
     This is run by the worker when the task is to be retried.
 
-    :param exc: The exception sent to :meth:`retry`.
+    :param exc: The exception sent to :meth:`~@Task.retry`.
     :param task_id: Unique id of the retried task.
     :param args: Original arguments for the retried task.
     :param kwargs: Original keyword arguments for the retried task.
@@ -881,33 +876,26 @@ yourself:
 
 .. code-block:: python
 
-    >>> from celery import registry
-    >>> from celery import task
-    >>> registry.tasks
-    {'celery.delete_expired_task_meta':
-        <PeriodicTask: celery.delete_expired_task_meta (periodic)>,
-     'celery.task.http.HttpDispatchTask':
-        <Task: celery.task.http.HttpDispatchTask (regular)>,
-     'celery.execute_remote':
-        <Task: celery.execute_remote (regular)>,
-     'celery.map_async':
-        <Task: celery.map_async (regular)>,
-     'celery.ping':
-        <Task: celery.ping (regular)>}
-
-This is the list of tasks built-in to celery.  Note that we had to import
-`celery.task` first for these to show up.  This is because the tasks will
-only be registered when the module they are defined in is imported.
+    >>> from celery import current_app
+    >>> current_app.tasks
+    {'celery.chord_unlock':
+        <@task: celery.chord_unlock>,
+     'celery.backend_cleanup':
+        <@task: celery.backend_cleanup>,
+     'celery.chord':
+        <@task: celery.chord>}
+
+This is the list of tasks built-in to celery.  Note that tasks
+will only be registered when the module they are defined in is imported.
 
 The default loader imports any modules listed in the
 :setting:`CELERY_IMPORTS` setting.
 
-The entity responsible for registering your task in the registry is a
-meta class, :class:`~celery.task.base.TaskType`.  This is the default
-meta class for :class:`~celery.task.base.BaseTask`.
+The entity responsible for registering your task in the registry is the
+metaclass: :class:`~celery.task.base.TaskType`.
 
 If you want to register your task manually you can mark the
-task as :attr:`~celery.task.base.BaseTask.abstract`:
+task as :attr:`~@Task.abstract`:
 
 .. code-block:: python
 
@@ -936,7 +924,7 @@ Ignore results you don't want
 -----------------------------
 
 If you don't care about the results of a task, be sure to set the
-:attr:`~celery.task.base.BaseTask.ignore_result` option, as storing results
+:attr:`~@Task.ignore_result` option, as storing results
 wastes time and resources.
 
 .. code-block:: python
@@ -1128,7 +1116,7 @@ that automatically expands some abbreviations in it:
         article.save()
 
 First, an author creates an article and saves it, then the author
-clicks on a button that initiates the abbreviation task.
+clicks on a button that initiates the abbreviation task::
 
     >>> article = Article.objects.get(id=102)
     >>> expand_abbreviations.delay(model_object)

docs/userguide/workers.rst

@@ -48,7 +48,7 @@ signal).
 If the worker won't shutdown after considerate time, for example because
 of tasks stuck in an infinite-loop, you can use the :sig:`KILL` signal to
 force terminate the worker, but be aware that currently executing tasks will
-be lost (unless the tasks have the :attr:`~celery.task.base.Task.acks_late`
+be lost (unless the tasks have the :attr:`~@Task.acks_late`
 option set).
 
 Also as processes can't override the :sig:`KILL` signal, the worker will
@@ -126,7 +126,7 @@ time limit kills it:
     from myapp import celery
     from celery.exceptions import SoftTimeLimitExceeded
 
-    @celery.task()
+    @celery.task
     def mytask():
         try:
             do_work()
@@ -257,13 +257,13 @@ to the number of destination hosts.
 
 .. _worker-broadcast-fun:
 
-The :func:`~celery.task.control.broadcast` function.
+The :meth:`~@control.broadcast` function.
 ----------------------------------------------------
 
 This is the client function used to send commands to the workers.
 Some remote control commands also have higher-level interfaces using
-:func:`~celery.task.control.broadcast` in the background, like
-:func:`~celery.task.control.rate_limit` and :func:`~celery.task.control.ping`.
+:meth:`~@control.broadcast` in the background, like
+:meth:`~@control.rate_limit` and :meth:`~@control.ping`.
 
 Sending the :control:`rate_limit` command and keyword arguments::
 
@@ -293,7 +293,7 @@ to receive the command::
 
 Of course, using the higher-level interface to set rate limits is much
 more convenient, but there are commands that can only be requested
-using :func:`~celery.task.control.broadcast`.
+using :meth:`~@control.broadcast`.
 
 .. _worker-rate-limits:
 
@@ -376,7 +376,7 @@ a custom timeout::
      {'worker2.example.com': 'pong'},
      {'worker3.example.com': 'pong'}]
 
-:func:`~celery.task.control.ping` also supports the `destination` argument,
+:meth:`~@control.ping` also supports the `destination` argument,
 so you can specify which workers to ping::
 
     >>> ping(['worker2.example.com', 'worker3.example.com'])
@@ -489,7 +489,7 @@ then import them using the :setting:`CELERY_IMPORTS` setting::
 Inspecting workers
 ==================
 
-:class:`celery.task.control.inspect` lets you inspect running workers.  It
+:class:`@control.inspect` lets you inspect running workers.  It
 uses remote control commands under the hood.
 
 .. code-block:: python
@@ -510,7 +510,7 @@ Dump of registered tasks
 ------------------------
 
 You can get a list of tasks registered in the worker using the
-:meth:`~celery.task.control.inspect.registered`::
+:meth:`~@control.inspect.registered`::
 
     >>> i.registered()
     [{'worker1.example.com': ['celery.delete_expired_task_meta',
@@ -527,7 +527,7 @@ Dump of currently executing tasks
 ---------------------------------
 
 You can get a list of active tasks using
-:meth:`~celery.task.control.inspect.active`::
+:meth:`~@control.inspect.active`::
 
     >>> i.active()
     [{'worker1.example.com':
@@ -542,7 +542,7 @@ Dump of scheduled (ETA) tasks
 -----------------------------
 
 You can get a list of tasks waiting to be scheduled by using
-:meth:`~celery.task.control.inspect.scheduled`::
+:meth:`~@control.inspect.scheduled`::
 
     >>> i.scheduled()
     [{'worker1.example.com':
@@ -570,7 +570,7 @@ Reserved tasks are tasks that has been received, but is still waiting to be
 executed.
 
 You can get a list of these using
-:meth:`~celery.task.control.inspect.reserved`::
+:meth:`~@control.inspect.reserved`::
 
     >>> i.reserved()
     [{'worker1.example.com':