<commit_before>=========================
Django shortcut functions
=========================

.. module:: django.shortcuts
   :synopsis:
       Convenience shortcuts that span multiple levels of Django's MVC stack.

.. index:: shortcuts

The package ``django.shortcuts`` collects helper functions and classes that
"span" multiple levels of MVC. In other words, these functions/classes
introduce controlled coupling for convenience's sake.

``render``
==========

.. function:: render(request, template_name[, dictionary][, context_instance][, content_type][, status][, current_app][, dirs])

   Combines a given template with a given context dictionary and returns an
   :class:`~django.http.HttpResponse` object with that rendered text.

   :func:`render()` is the same as a call to
   :func:`render_to_response()` with a ``context_instance`` argument that
   forces the use of a :class:`~django.template.RequestContext`.

   Django does not provide a shortcut function which returns a
   :class:`~django.template.response.TemplateResponse` because the constructor
   of :class:`~django.template.response.TemplateResponse` offers the same level
   of convenience as :func:`render()`.

Required arguments
------------------

``request``
    The request object used to generate this response.

``template_name``
    The full name of a template to use or sequence of template names.

Optional arguments
------------------

``dictionary``
    A dictionary of values to add to the template context. By default, this
    is an empty dictionary. If a value in the dictionary is callable, the
    view will call it just before rendering the template.

``context_instance``
    The context instance to render the template with. By default, the template
    will be rendered with a ``RequestContext`` instance (filled with values from
    ``request`` and ``dictionary``).

``content_type``
    The MIME type to use for the resulting document. Defaults to the value of
    the :setting:`DEFAULT_CONTENT_TYPE` setting.

``status``
    The status code for the response. Defaults to ``200``.

``current_app``
    A hint indicating which application contains the current view. See the
    :ref:`namespaced URL resolution strategy <topics-http-reversing-url-namespaces>`
    for more information.

``dirs``
    A tuple or list of values to override the :setting:`TEMPLATE_DIRS` setting.

.. versionchanged:: 1.7

   The ``dirs`` parameter was added.

Example
-------

The following example renders the template ``myapp/index.html`` with the
MIME type :mimetype:`application/xhtml+xml`::

    from django.shortcuts import render

    def my_view(request):
        # View code here...
        return render(request, 'myapp/index.html', {"foo": "bar"},
            content_type="application/xhtml+xml")

This example is equivalent to::

    from django.http import HttpResponse
    from django.template import RequestContext, loader

    def my_view(request):
        # View code here...
        t = loader.get_template('myapp/index.html')
        c = RequestContext(request, {'foo': 'bar'})
        return HttpResponse(t.render(c),
            content_type="application/xhtml+xml")

If you want to override the :setting:`TEMPLATE_DIRS` setting, use the
``dirs`` parameter::

    from django.shortcuts import render

    def my_view(request):
        # View code here...
        return render(request, 'index.html', dirs=('custom_templates',))

``render_to_response``
======================

.. function:: render_to_response(template_name[, dictionary][, context_instance][, content_type][, dirs])

   Renders a given template with a given context dictionary and returns an
   :class:`~django.http.HttpResponse` object with that rendered text.

Required arguments
------------------

``template_name``
    The full name of a template to use or sequence of template names. If a
    sequence is given, the first template that exists will be used. See the
    :ref:`template loader documentation <ref-templates-api-the-python-api>`
    for more information on how templates are found.

Optional arguments
------------------

``dictionary``
    A dictionary of values to add to the template context. By default, this
    is an empty dictionary. If a value in the dictionary is callable, the
    view will call it just before rendering the template.

``context_instance``
    The context instance to render the template with. By default, the template
    will be rendered with a :class:`~django.template.Context` instance (filled
    with values from ``dictionary``). If you need to use :ref:`context
    processors <subclassing-context-requestcontext>`, render the template with
    a :class:`~django.template.RequestContext` instance instead. Your code
    might look something like this::

        return render_to_response('my_template.html',
                                  my_data_dictionary,
                                  context_instance=RequestContext(request))

``content_type``
    The MIME type to use for the resulting document. Defaults to the value of
    the :setting:`DEFAULT_CONTENT_TYPE` setting.

``dirs``
    A tuple or list of values to override the :setting:`TEMPLATE_DIRS` setting.

.. versionchanged:: 1.7

   The ``dirs`` parameter was added.

Example
-------

The following example renders the template ``myapp/index.html`` with the
MIME type :mimetype:`application/xhtml+xml`::

    from django.shortcuts import render_to_response

    def my_view(request):
        # View code here...
        return render_to_response('myapp/index.html', {"foo": "bar"},
            mimetype="application/xhtml+xml")

This example is equivalent to::

    from django.http import HttpResponse
    from django.template import Context, loader

    def my_view(request):
        # View code here...
        t = loader.get_template('myapp/index.html')
        c = Context({'foo': 'bar'})
        return HttpResponse(t.render(c),
            content_type="application/xhtml+xml")

If you want to override the :setting:`TEMPLATE_DIRS` setting, use the
``dirs`` parameter::

    from django.shortcuts import render_to_response

    def my_view(request):
        # View code here...
        return render_to_response('index.html', dirs=('custom_templates',))

``redirect``
============

.. function:: redirect(to[, permanent=False], *args, **kwargs)

   Returns an :class:`~django.http.HttpResponseRedirect` to the appropriate URL
   for the arguments passed.

   The arguments could be:

   * A model: the model's :meth:`~django.db.models.Model.get_absolute_url()`
     function will be called.

   * A view name, possibly with arguments: :func:`urlresolvers.reverse
     <django.core.urlresolvers.reverse>` will be used to reverse-resolve the
     name.

   * An absolute or relative URL, which will be used as-is for the redirect
     location.

   By default issues a temporary redirect; pass ``permanent=True`` to issue a
   permanent redirect.

   .. versionchanged:: 1.7

       The ability to use relative URLs was added.

Examples
--------

You can use the :func:`redirect` function in a number of ways.

1. By passing some object; that object's
   :meth:`~django.db.models.Model.get_absolute_url` method will be called
   to figure out the redirect URL::

        from django.shortcuts import redirect

        def my_view(request):
            ...
            object = MyModel.objects.get(...)
            return redirect(object)

2. By passing the name of a view and optionally some positional or
   keyword arguments; the URL will be reverse resolved using the
   :func:`~django.core.urlresolvers.reverse` method::

        def my_view(request):
            ...
            return redirect('some-view-name', foo='bar')

3. By passing a hardcoded URL to redirect to::

        def my_view(request):
            ...
            return redirect('/some/url/')

   This also works with full URLs::

        def my_view(request):
            ...
            return redirect('http://example.com/')

By default, :func:`redirect` returns a temporary redirect. All of the above
forms accept a ``permanent`` argument; if set to ``True`` a permanent redirect
will be returned::

    def my_view(request):
        ...
        object = MyModel.objects.get(...)
        return redirect(object, permanent=True)

``get_object_or_404``
=====================

.. function:: get_object_or_404(klass, *args, **kwargs)

   Calls :meth:`~django.db.models.query.QuerySet.get()` on a given model manager,
   but it raises :class:`~django.http.Http404` instead of the model's
   :class:`~django.core.exceptions.DoesNotExist` exception.

Required arguments
------------------

``klass``
    A :class:`~django.db.models.Model` class,
    a :class:`~django.db.models.Manager`,
    or a :class:`~django.db.models.query.QuerySet` instance from which to get
    the object.

``**kwargs``
    Lookup parameters, which should be in the format accepted by ``get()`` and
    ``filter()``.

Example
-------

The following example gets the object with the primary key of 1 from
``MyModel``::

    from django.shortcuts import get_object_or_404

    def my_view(request):
        my_object = get_object_or_404(MyModel, pk=1)

This example is equivalent to::

    from django.http import Http404

    def my_view(request):
        try:
            my_object = MyModel.objects.get(pk=1)
        except MyModel.DoesNotExist:
            raise Http404

The most common use case is to pass a :class:`~django.db.models.Model`, as
shown above. However, you can also pass a
:class:`~django.db.models.query.QuerySet` instance::

    queryset = Book.objects.filter(title__startswith='M')
    get_object_or_404(queryset, pk=1)

The above example is a bit contrived since it's equivalent to doing::

    get_object_or_404(Book, title__startswith='M', pk=1)

but it can be useful if you are passed the ``queryset`` variable from somewhere
else.

Finally, you can also use a :class:`~django.db.models.Manager`. This is useful
for example if you have a
:ref:`custom manager<custom-managers>`::

    get_object_or_404(Book.dahl_objects, title='Matilda')

You can also use
:class:`related managers<django.db.models.fields.related.RelatedManager>`::

    author = Author.objects.get(name='<NAME>')
    get_object_or_404(author.book_set, title='Matilda')

Note: As with ``get()``, a
:class:`~django.core.exceptions.MultipleObjectsReturned` exception
will be raised if more than one object is found.

``get_list_or_404``
===================

.. function:: get_list_or_404(klass, *args, **kwargs)

   Returns the result of :meth:`~django.db.models.query.QuerySet.filter()` on a
   given model manager cast to a list, raising :class:`~django.http.Http404` if
   the resulting list is empty.

Required arguments
------------------

``klass``
    A :class:`~django.db.models.Model`, :class:`~django.db.models.Manager` or
    :class:`~django.db.models.query.QuerySet` instance from which to get the
    list.

``**kwargs``
    Lookup parameters, which should be in the format accepted by ``get()`` and
    ``filter()``.

Example
-------

The following example gets all published objects from ``MyModel``::

    from django.shortcuts import get_list_or_404

    def my_view(request):
        my_objects = get_list_or_404(MyModel, published=True)

This example is equivalent to::

    from django.http import Http404

    def my_view(request):
        my_objects = list(MyModel.objects.filter(published=True))
        if not my_objects:
            raise Http404
<commit_msg>[1.7.x] Removed a doc reference to the deprecated `mimetype` kwarg.<commit_after>=========================
Django shortcut functions
=========================

.. module:: django.shortcuts
   :synopsis:
       Convenience shortcuts that span multiple levels of Django's MVC stack.

.. index:: shortcuts

The package ``django.shortcuts`` collects helper functions and classes that
"span" multiple levels of MVC. In other words, these functions/classes
introduce controlled coupling for convenience's sake.

``render``
==========

.. function:: render(request, template_name[, dictionary][, context_instance][, content_type][, status][, current_app][, dirs])

   Combines a given template with a given context dictionary and returns an
   :class:`~django.http.HttpResponse` object with that rendered text.

   :func:`render()` is the same as a call to
   :func:`render_to_response()` with a ``context_instance`` argument that
   forces the use of a :class:`~django.template.RequestContext`.

   Django does not provide a shortcut function which returns a
   :class:`~django.template.response.TemplateResponse` because the constructor
   of :class:`~django.template.response.TemplateResponse` offers the same level
   of convenience as :func:`render()`.

Required arguments
------------------

``request``
    The request object used to generate this response.

``template_name``
    The full name of a template to use or sequence of template names.

Optional arguments
------------------

``dictionary``
    A dictionary of values to add to the template context. By default, this
    is an empty dictionary. If a value in the dictionary is callable, the
    view will call it just before rendering the template.

``context_instance``
    The context instance to render the template with. By default, the template
    will be rendered with a ``RequestContext`` instance (filled with values from
    ``request`` and ``dictionary``).

``content_type``
    The MIME type to use for the resulting document. Defaults to the value of
    the :setting:`DEFAULT_CONTENT_TYPE` setting.

``status``
    The status code for the response. Defaults to ``200``.

``current_app``
    A hint indicating which application contains the current view. See the
    :ref:`namespaced URL resolution strategy <topics-http-reversing-url-namespaces>`
    for more information.

``dirs``
    A tuple or list of values to override the :setting:`TEMPLATE_DIRS` setting.

.. versionchanged:: 1.7

   The ``dirs`` parameter was added.

Example
-------

The following example renders the template ``myapp/index.html`` with the
MIME type :mimetype:`application/xhtml+xml`::

    from django.shortcuts import render

    def my_view(request):
        # View code here...
        return render(request, 'myapp/index.html', {"foo": "bar"},
            content_type="application/xhtml+xml")

This example is equivalent to::

    from django.http import HttpResponse
    from django.template import RequestContext, loader

    def my_view(request):
        # View code here...
        t = loader.get_template('myapp/index.html')
        c = RequestContext(request, {'foo': 'bar'})
        return HttpResponse(t.render(c),
            content_type="application/xhtml+xml")

If you want to override the :setting:`TEMPLATE_DIRS` setting, use the
``dirs`` parameter::

    from django.shortcuts import render

    def my_view(request):
        # View code here...
        return render(request, 'index.html', dirs=('custom_templates',))

``render_to_response``
======================

.. function:: render_to_response(template_name[, dictionary][, context_instance][, content_type][, dirs])

   Renders a given template with a given context dictionary and returns an
   :class:`~django.http.HttpResponse` object with that rendered text.

Required arguments
------------------

``template_name``
    The full name of a template to use or sequence of template names. If a
    sequence is given, the first template that exists will be used. See the
    :ref:`template loader documentation <ref-templates-api-the-python-api>`
    for more information on how templates are found.

Optional arguments
------------------

``dictionary``
    A dictionary of values to add to the template context. By default, this
    is an empty dictionary. If a value in the dictionary is callable, the
    view will call it just before rendering the template.

``context_instance``
    The context instance to render the template with. By default, the template
    will be rendered with a :class:`~django.template.Context` instance (filled
    with values from ``dictionary``). If you need to use :ref:`context
    processors <subclassing-context-requestcontext>`, render the template with
    a :class:`~django.template.RequestContext` instance instead. Your code
    might look something like this::

        return render_to_response('my_template.html',
                                  my_data_dictionary,
                                  context_instance=RequestContext(request))

``content_type``
    The MIME type to use for the resulting document. Defaults to the value of
    the :setting:`DEFAULT_CONTENT_TYPE` setting.

``dirs``
    A tuple or list of values to override the :setting:`TEMPLATE_DIRS` setting.

.. versionchanged:: 1.7

   The ``dirs`` parameter was added.

Example
-------

The following example renders the template ``myapp/index.html`` with the
MIME type :mimetype:`application/xhtml+xml`::

    from django.shortcuts import render_to_response

    def my_view(request):
        # View code here...
        return render_to_response('myapp/index.html', {"foo": "bar"},
            content_type="application/xhtml+xml")

This example is equivalent to::

    from django.http import HttpResponse
    from django.template import Context, loader

    def my_view(request):
        # View code here...
        t = loader.get_template('myapp/index.html')
        c = Context({'foo': 'bar'})
        return HttpResponse(t.render(c),
            content_type="application/xhtml+xml")

If you want to override the :setting:`TEMPLATE_DIRS` setting, use the
``dirs`` parameter::

    from django.shortcuts import render_to_response

    def my_view(request):
        # View code here...
        return render_to_response('index.html', dirs=('custom_templates',))

``redirect``
============

.. function:: redirect(to[, permanent=False], *args, **kwargs)

   Returns an :class:`~django.http.HttpResponseRedirect` to the appropriate URL
   for the arguments passed.

   The arguments could be:

   * A model: the model's :meth:`~django.db.models.Model.get_absolute_url()`
     function will be called.

   * A view name, possibly with arguments: :func:`urlresolvers.reverse
     <django.core.urlresolvers.reverse>` will be used to reverse-resolve the
     name.

   * An absolute or relative URL, which will be used as-is for the redirect
     location.

   By default issues a temporary redirect; pass ``permanent=True`` to issue a
   permanent redirect.

   .. versionchanged:: 1.7

       The ability to use relative URLs was added.

Examples
--------

You can use the :func:`redirect` function in a number of ways.

1. By passing some object; that object's
   :meth:`~django.db.models.Model.get_absolute_url` method will be called
   to figure out the redirect URL::

        from django.shortcuts import redirect

        def my_view(request):
            ...
            object = MyModel.objects.get(...)
            return redirect(object)

2. By passing the name of a view and optionally some positional or
   keyword arguments; the URL will be reverse resolved using the
   :func:`~django.core.urlresolvers.reverse` method::

        def my_view(request):
            ...
            return redirect('some-view-name', foo='bar')

3. By passing a hardcoded URL to redirect to::

        def my_view(request):
            ...
            return redirect('/some/url/')

   This also works with full URLs::

        def my_view(request):
            ...
            return redirect('http://example.com/')

By default, :func:`redirect` returns a temporary redirect. All of the above
forms accept a ``permanent`` argument; if set to ``True`` a permanent redirect
will be returned::

    def my_view(request):
        ...
        object = MyModel.objects.get(...)
        return redirect(object, permanent=True)

``get_object_or_404``
=====================

.. function:: get_object_or_404(klass, *args, **kwargs)

   Calls :meth:`~django.db.models.query.QuerySet.get()` on a given model manager,
   but it raises :class:`~django.http.Http404` instead of the model's
   :class:`~django.core.exceptions.DoesNotExist` exception.

Required arguments
------------------

``klass``
    A :class:`~django.db.models.Model` class,
    a :class:`~django.db.models.Manager`,
    or a :class:`~django.db.models.query.QuerySet` instance from which to get
    the object.

``**kwargs``
    Lookup parameters, which should be in the format accepted by ``get()`` and
    ``filter()``.

Example
-------

The following example gets the object with the primary key of 1 from
``MyModel``::

    from django.shortcuts import get_object_or_404

    def my_view(request):
        my_object = get_object_or_404(MyModel, pk=1)

This example is equivalent to::

    from django.http import Http404

    def my_view(request):
        try:
            my_object = MyModel.objects.get(pk=1)
        except MyModel.DoesNotExist:
            raise Http404

The most common use case is to pass a :class:`~django.db.models.Model`, as
shown above. However, you can also pass a
:class:`~django.db.models.query.QuerySet` instance::

    queryset = Book.objects.filter(title__startswith='M')
    get_object_or_404(queryset, pk=1)

The above example is a bit contrived since it's equivalent to doing::

    get_object_or_404(Book, title__startswith='M', pk=1)

but it can be useful if you are passed the ``queryset`` variable from somewhere
else.

Finally, you can also use a :class:`~django.db.models.Manager`. This is useful
for example if you have a
:ref:`custom manager<custom-managers>`::

    get_object_or_404(Book.dahl_objects, title='Matilda')

You can also use
:class:`related managers<django.db.models.fields.related.RelatedManager>`::

    author = Author.objects.get(name='<NAME>')
    get_object_or_404(author.book_set, title='Matilda')

Note: As with ``get()``, a
:class:`~django.core.exceptions.MultipleObjectsReturned` exception
will be raised if more than one object is found.

``get_list_or_404``
===================

.. function:: get_list_or_404(klass, *args, **kwargs)

   Returns the result of :meth:`~django.db.models.query.QuerySet.filter()` on a
   given model manager cast to a list, raising :class:`~django.http.Http404` if
   the resulting list is empty.

Required arguments
------------------

``klass``
    A :class:`~django.db.models.Model`, :class:`~django.db.models.Manager` or
    :class:`~django.db.models.query.QuerySet` instance from which to get the
    list.

``**kwargs``
    Lookup parameters, which should be in the format accepted by ``get()`` and
    ``filter()``.

Example
-------

The following example gets all published objects from ``MyModel``::

    from django.shortcuts import get_list_or_404

    def my_view(request):
        my_objects = get_list_or_404(MyModel, published=True)

This example is equivalent to::

    from django.http import Http404

    def my_view(request):
        my_objects = list(MyModel.objects.filter(published=True))
        if not my_objects:
            raise Http404

{'fraction_non_alphanumeric': 0.12389495579823193, 'fraction_numerical': 0.0062402496099844, 'mean_word_length': 3.346769636466378, 'pattern_counts': {'":': 4, '<': 17, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 12}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5875297', 'n_tokens_mistral': 6601, 'n_tokens_neox': 6274, 'n_words': 2261}