mirror of
				https://github.com/django/django.git
				synced 2025-10-31 09:41:08 +00:00 
			
		
		
		
	Fixed #14000 - remove versionadded/changed tags for Django 1.0 and 1.1
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15055 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
		| @@ -2,8 +2,6 @@ | ||||
| Writing custom django-admin commands | ||||
| ==================================== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Applications can register their own actions with ``manage.py``. For example, | ||||
| you might want to add a ``manage.py`` action for a Django app that you're | ||||
| distributing. In this document, we will be building a custom ``closepoll`` | ||||
|   | ||||
| @@ -2,7 +2,6 @@ | ||||
| Writing custom model fields | ||||
| =========================== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
| .. currentmodule:: django.db.models | ||||
|  | ||||
| Introduction | ||||
|   | ||||
| @@ -155,8 +155,6 @@ will use the function's name as the filter name. | ||||
| Filters and auto-escaping | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| When writing a custom filter, give some thought to how the filter will interact | ||||
| with Django's auto-escaping behavior. Note that three types of strings can be | ||||
| passed around inside the template code: | ||||
| @@ -426,8 +424,6 @@ without having to be parsed multiple times. | ||||
| Auto-escaping considerations | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| The output from template tags is **not** automatically run through the | ||||
| auto-escaping filters. However, there are still a couple of things you should | ||||
| keep in mind when writing a template tag. | ||||
| @@ -605,10 +601,6 @@ Now your tag should begin to look like this:: | ||||
|             raise template.TemplateSyntaxError, "%r tag's argument should be in quotes" % tag_name | ||||
|         return FormatTimeNode(date_to_be_formatted, format_string[1:-1]) | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|     Variable resolution has changed in the 1.0 release of Django. ``template.resolve_variable()`` | ||||
|     has been deprecated in favor of a new ``template.Variable`` class. | ||||
|  | ||||
| You also have to change the renderer to retrieve the actual contents of the | ||||
| ``date_updated`` property of the ``blog_entry`` object.  This can be | ||||
| accomplished by using the ``Variable()`` class in ``django.template``. | ||||
|   | ||||
| @@ -64,9 +64,6 @@ This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the | ||||
| Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE | ||||
| <django-settings-module>` so mod_python knows which settings to use. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|     The ``PythonOption django.root ...`` is new in this version. | ||||
|  | ||||
| Because mod_python does not know we are serving this site from underneath the | ||||
| ``/mysite/`` prefix, this value needs to be passed through to the mod_python | ||||
| handler in Django, via the ``PythonOption django.root ...`` line. The value set | ||||
|   | ||||
| @@ -38,9 +38,6 @@ activate the admin site for your installation, do these three things: | ||||
|       need to know is that it maps URL roots to applications. In the end, you | ||||
|       should have a ``urls.py`` file that looks like this: | ||||
|  | ||||
|     .. versionchanged:: 1.1 | ||||
|         The method for adding admin urls has changed in Django 1.1. | ||||
|  | ||||
|       .. parsed-literal:: | ||||
|  | ||||
|           from django.conf.urls.defaults import * | ||||
|   | ||||
| @@ -26,8 +26,6 @@ The following backends are available in :mod:`django.contrib.auth.backends`: | ||||
|  | ||||
| .. class:: RemoteUserBackend | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     Use this backend to take advantage of external-to-Django-handled | ||||
|     authentication.  It authenticates using usernames passed in | ||||
|     :attr:`request.META['REMOTE_USER'] <django.http.HttpRequest.META>`.  See | ||||
|   | ||||
| @@ -2,8 +2,6 @@ | ||||
| Admin actions | ||||
| ============= | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| .. currentmodule:: django.contrib.admin | ||||
|  | ||||
| The basic workflow of Django's admin is, in a nutshell, "select an object, | ||||
|   | ||||
| @@ -434,8 +434,6 @@ subclass:: | ||||
|  | ||||
| .. attribute:: ModelAdmin.list_editable | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     Set ``list_editable`` to a list of field names on the model which will | ||||
|     allow editing on the change list page. That is, fields listed in | ||||
|     ``list_editable`` will be displayed as form widgets on the change list | ||||
| @@ -678,8 +676,6 @@ subclass:: | ||||
|  | ||||
| .. attribute:: ModelAdmin.formfield_overrides | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     This provides a quick-and-dirty way to override some of the | ||||
|     :class:`~django.forms.Field` options for use in the admin. | ||||
|     ``formfield_overrides`` is a dictionary mapping a field class to a dict of | ||||
| @@ -722,16 +718,12 @@ subclass:: | ||||
|  | ||||
| .. attribute:: ModelAdmin.actions | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     A list of actions to make available on the change list page. See | ||||
|     :doc:`/ref/contrib/admin/actions` for details. | ||||
|  | ||||
| .. attribute:: ModelAdmin.actions_on_top | ||||
| .. attribute:: ModelAdmin.actions_on_bottom | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     Controls where on the page the actions bar appears. By default, the admin | ||||
|     changelist displays actions at the top of the page (``actions_on_top = True; | ||||
|     actions_on_bottom = False``). | ||||
| @@ -843,8 +835,6 @@ templates used by the :class:`ModelAdmin` views: | ||||
|  | ||||
| .. method:: ModelAdmin.get_urls(self) | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     The ``get_urls`` method on a ``ModelAdmin`` returns the URLs to be used for | ||||
|     that ModelAdmin in the same way as a URLconf.  Therefore you can extend | ||||
|     them as documented in :doc:`/topics/http/urls`:: | ||||
| @@ -903,8 +893,6 @@ templates used by the :class:`ModelAdmin` views: | ||||
|  | ||||
| .. method:: ModelAdmin.formfield_for_foreignkey(self, db_field, request, **kwargs) | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     The ``formfield_for_foreignkey`` method on a ``ModelAdmin`` allows you to | ||||
|     override the default formfield for a foreign key field. For example, to | ||||
|     return a subset of objects for this foreign key field based on the user:: | ||||
| @@ -920,8 +908,6 @@ templates used by the :class:`ModelAdmin` views: | ||||
|  | ||||
| .. method:: ModelAdmin.formfield_for_manytomany(self, db_field, request, **kwargs) | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     Like the ``formfield_for_foreignkey`` method, the | ||||
|     ``formfield_for_manytomany`` method can be overridden to change the | ||||
|     default formfield for a many to many field. For example, if an owner can | ||||
| @@ -1119,9 +1105,6 @@ adds some of its own (the shared features are actually defined in the | ||||
| - :attr:`~ModelAdmin.prepopulated_fields` | ||||
| - :attr:`~ModelAdmin.radio_fields` | ||||
| - :attr:`~InlineModelAdmin.raw_id_fields` | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| - :meth:`~ModelAdmin.formfield_for_foreignkey` | ||||
| - :meth:`~ModelAdmin.formfield_for_manytomany` | ||||
|  | ||||
| @@ -1512,8 +1495,6 @@ creating your own ``AdminSite`` instance (see below), and changing the | ||||
|     Python class), and register your models and ``ModelAdmin`` subclasses | ||||
|     with it instead of using the default. | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     When constructing an instance of an ``AdminSite``, you are able to provide | ||||
|     a unique instance name using the ``name`` argument to the constructor. This | ||||
|     instance name is used to identify the instance, especially when | ||||
| @@ -1607,10 +1588,6 @@ It's easy to create multiple instances of the admin site on the same | ||||
| Django-powered Web site. Just create multiple instances of ``AdminSite`` and | ||||
| root each one at a different URL. | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|     The method for hooking ``AdminSite`` instances into urls has changed in | ||||
|     Django 1.1. | ||||
|  | ||||
| In this example, the URLs ``/basic-admin/`` and ``/advanced-admin/`` feature | ||||
| separate versions of the admin site -- using the ``AdminSite`` instances | ||||
| ``myproject.admin.basic_site`` and ``myproject.admin.advanced_site``, | ||||
| @@ -1633,8 +1610,6 @@ is only necessary if you are using more than one ``AdminSite``. | ||||
| Adding views to admin sites | ||||
| --------------------------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Just like :class:`ModelAdmin`, :class:`AdminSite` provides a | ||||
| :meth:`~django.contrib.admin.ModelAdmin.get_urls()` method | ||||
| that can be overridden to define additional views for the site. To add | ||||
| @@ -1654,8 +1629,6 @@ a pattern for your new view. | ||||
| Reversing Admin URLs | ||||
| ==================== | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| When an :class:`AdminSite` is deployed, the views provided by that site are | ||||
| accessible using Django's :ref:`URL reversing system <naming-url-patterns>`. | ||||
|  | ||||
|   | ||||
| @@ -241,7 +241,6 @@ it. | ||||
| Exceptions | ||||
| ---------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
| .. versionchanged:: 1.2 | ||||
|     Import paths for the decorators below were changed. | ||||
|  | ||||
|   | ||||
| @@ -17,8 +17,6 @@ custom Django application. | ||||
| A flatpage can use a custom template or a default, systemwide flatpage | ||||
| template. It can be associated with one, or multiple, sites. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| The content field may optionally be left blank if you prefer to put your | ||||
| content in a custom template. | ||||
|  | ||||
|   | ||||
| @@ -5,8 +5,6 @@ Form wizard | ||||
| .. module:: django.contrib.formtools.wizard | ||||
|     :synopsis: Splits forms across multiple Web pages. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Django comes with an optional "form wizard" application that splits | ||||
| :doc:`forms </topics/forms/index>` across multiple Web pages. It maintains | ||||
| state in hashed HTML :samp:`<input type="hidden">` fields, and the data isn't | ||||
|   | ||||
| @@ -459,8 +459,6 @@ systems and coordinate transformation:: | ||||
|  | ||||
|    .. classmethod:: from_bbox(bbox) | ||||
|  | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
|    Constructs a :class:`Polygon` from the given bounding-box (a 4-tuple). | ||||
|  | ||||
|    .. method:: __len__ | ||||
| @@ -601,8 +599,6 @@ systems and coordinate transformation:: | ||||
|  | ||||
|    .. attribute:: kml | ||||
|  | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
|    Returns a string representation of this geometry in KML format. | ||||
|  | ||||
|    .. attribute:: wkb_size | ||||
| @@ -889,8 +885,6 @@ systems and coordinate transformation:: | ||||
|  | ||||
|    .. method:: expand_to_include(self, *args) | ||||
|  | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
| Coordinate System Objects | ||||
| ========================= | ||||
|  | ||||
| @@ -992,8 +986,6 @@ Coordinate System Objects | ||||
|    Import spatial reference from PROJ.4 string. | ||||
|  | ||||
|    .. method:: import_user_input(user_input) | ||||
|    | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
|    .. method:: import_wkt(wkt) | ||||
|  | ||||
|   | ||||
| @@ -835,8 +835,6 @@ Reverse the coordinate order of the geometry field, and attaches as a | ||||
|  | ||||
| .. method:: GeoQuerySet.snap_to_grid(*args, **kwargs) | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Snap all points of the input geometry to the grid.  How the | ||||
| geometry is snapped to the grid depends on how many numeric | ||||
| (either float, integer, or long) arguments are given. | ||||
| @@ -957,8 +955,6 @@ __ http://geohash.org/ | ||||
|  | ||||
| .. method:: GeoQuerySet.geojson(**kwargs) | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| *Availability*: PostGIS | ||||
|  | ||||
| Attaches a ``geojson`` attribute to every model in the queryset that contains the | ||||
| @@ -1102,7 +1098,6 @@ the ``GeoQuerySet``; otherwise sets with ``None``. | ||||
|  | ||||
| Spatial Aggregates | ||||
| ================== | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Aggregate Methods | ||||
| ----------------- | ||||
| @@ -1112,8 +1107,6 @@ Aggregate Methods | ||||
|  | ||||
| .. method:: GeoQuerySet.collect(**kwargs) | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| *Availability*: PostGIS | ||||
|  | ||||
| Returns a ``GEOMETRYCOLLECTION`` or a ``MULTI`` geometry object from the geometry | ||||
|   | ||||
| @@ -33,10 +33,10 @@ features include: | ||||
| * A BSD-licensed interface to the GEOS geometry routines, implemented purely | ||||
|   in Python using ``ctypes``. | ||||
| * Loosely-coupled to GeoDjango.  For example, :class:`GEOSGeometry` objects | ||||
|   may be used outside of a django project/application.  In other words,  | ||||
|   may be used outside of a django project/application.  In other words, | ||||
|   no need to have ``DJANGO_SETTINGS_MODULE`` set or use a database, etc. | ||||
| * Mutability: :class:`GEOSGeometry` objects may be modified. | ||||
| * Cross-platform and tested; compatible with Windows, Linux, Solaris, and Mac  | ||||
| * Cross-platform and tested; compatible with Windows, Linux, Solaris, and Mac | ||||
|   OS X platforms. | ||||
|  | ||||
| .. _geos-tutorial: | ||||
| @@ -44,7 +44,7 @@ features include: | ||||
| Tutorial | ||||
| ======== | ||||
|  | ||||
| This section contains a brief introduction and tutorial to using  | ||||
| This section contains a brief introduction and tutorial to using | ||||
| :class:`GEOSGeometry` objects. | ||||
|  | ||||
| Creating a Geometry | ||||
| @@ -75,7 +75,7 @@ return a :class:`GEOSGeometry` object from an input string or a file:: | ||||
|     >>> pnt = fromfile('/path/to/pnt.wkt') | ||||
|     >>> pnt = fromfile(open('/path/to/pnt.wkt')) | ||||
|  | ||||
| Geometries are Pythonic  | ||||
| Geometries are Pythonic | ||||
| ----------------------- | ||||
| :class:`GEOSGeometry` objects are 'Pythonic', in other words components may | ||||
| be accessed, modified, and iterated over using standard Python conventions. | ||||
| @@ -146,7 +146,7 @@ are accepted: | ||||
| =============  ====================== | ||||
| Format         Input Type | ||||
| =============  ====================== | ||||
| WKT / EWKT     ``str`` or ``unicode``  | ||||
| WKT / EWKT     ``str`` or ``unicode`` | ||||
| HEX / HEXEWKB  ``str`` or ``unicode`` | ||||
| WKB / EWKB     ``buffer`` | ||||
| GeoJSON        ``str`` or ``unicode`` | ||||
| @@ -161,7 +161,7 @@ Returns the coordinates of the geometry as a tuple. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.empty | ||||
|  | ||||
| Returns whether or not the set of points in the geometry is empty.  | ||||
| Returns whether or not the set of points in the geometry is empty. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.geom_type | ||||
|  | ||||
| @@ -219,11 +219,11 @@ definition. | ||||
|  | ||||
| Returns a boolean indicating whether the geometry is valid. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.valid_reason  | ||||
| .. attribute:: GEOSGeometry.valid_reason | ||||
|  | ||||
| .. versionadded:: 1.3  | ||||
| .. versionadded:: 1.3 | ||||
|  | ||||
| Returns a string describing the reason why a geometry is invalid.  | ||||
| Returns a string describing the reason why a geometry is invalid. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.srid | ||||
|  | ||||
| @@ -248,27 +248,27 @@ another object. | ||||
|  | ||||
| Returns the "extended" Well-Known Text of the geometry.  This representation | ||||
| is specific to PostGIS and is a super set of the OGC WKT standard. [#fnogc]_ | ||||
| Essentially the SRID is prepended to the WKT representation, for example  | ||||
| ``SRID=4326;POINT(5 23)``.  | ||||
| Essentially the SRID is prepended to the WKT representation, for example | ||||
| ``SRID=4326;POINT(5 23)``. | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
|    The output from this property does not include the 3dm, 3dz, and 4d  | ||||
|    The output from this property does not include the 3dm, 3dz, and 4d | ||||
|    information that PostGIS supports in its EWKT representations. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.hex | ||||
|  | ||||
| Returns the WKB of this Geometry in hexadecimal form.  Please note | ||||
| that the SRID and Z values are not included in this representation | ||||
| because it is not a part of the OGC specification (use the  | ||||
| because it is not a part of the OGC specification (use the | ||||
| :attr:`GEOSGeometry.hexewkb` property instead). | ||||
|  | ||||
| .. attribute:: GEOSGeometry.hexewkb | ||||
|  | ||||
| .. versionadded:: 1.2 | ||||
|  | ||||
| Returns the EWKB of this Geometry in hexadecimal form.  This is an  | ||||
| extension of the WKB specification that includes SRID and Z values  | ||||
| Returns the EWKB of this Geometry in hexadecimal form.  This is an | ||||
| extension of the WKB specification that includes SRID and Z values | ||||
| that are a part of this geometry. | ||||
|  | ||||
| .. note:: | ||||
| @@ -290,12 +290,12 @@ Alias for :attr:`GEOSGeometry.json`. | ||||
| .. attribute:: GEOSGeometry.kml | ||||
|  | ||||
| Returns a `KML`__ (Keyhole Markup Language) representation of the | ||||
| geometry.  This should only be used for geometries with an SRID of  | ||||
| geometry.  This should only be used for geometries with an SRID of | ||||
| 4326 (WGS84), but this restriction is not enforced. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.ogr | ||||
|  | ||||
| Returns an :class:`~django.contrib.gis.gdal.OGRGeometry` object  | ||||
| Returns an :class:`~django.contrib.gis.gdal.OGRGeometry` object | ||||
| correspondg to the GEOS geometry. | ||||
|  | ||||
| .. note:: | ||||
| @@ -344,7 +344,7 @@ Returns ``True`` if :meth:`GEOSGeometry.within` is ``False``. | ||||
| .. method:: GEOSGeometry.crosses(other) | ||||
|  | ||||
| Returns ``True`` if the DE-9IM intersection matrix for the two Geometries | ||||
| is ``T*T******`` (for a point and a curve,a point and an area or a line  | ||||
| is ``T*T******`` (for a point and a curve,a point and an area or a line | ||||
| and an area) ``0********`` (for two curves). | ||||
|  | ||||
| .. method:: GEOSGeometry.disjoint(other) | ||||
| @@ -354,7 +354,7 @@ is ``FF*FF****``. | ||||
|  | ||||
| .. method:: GEOSGeometry.equals(other) | ||||
|  | ||||
| Returns ``True`` if the DE-9IM intersection matrix for the two geometries  | ||||
| Returns ``True`` if the DE-9IM intersection matrix for the two geometries | ||||
| is ``T*F**FFF*``. | ||||
|  | ||||
| .. method:: GEOSGeometry.equals_exact(other, tolerance=0) | ||||
| @@ -377,8 +377,8 @@ is ``T*T***T**`` (for two points or two surfaces) ``1*T***T**`` | ||||
|  | ||||
| .. method:: GEOSGeometry.relate_pattern(other, pattern) | ||||
|  | ||||
| Returns ``True`` if the elements in the DE-9IM intersection matrix  | ||||
| for this geometry and the other matches the given ``pattern`` --  | ||||
| Returns ``True`` if the elements in the DE-9IM intersection matrix | ||||
| for this geometry and the other matches the given ``pattern`` -- | ||||
| a string of nine characters from the alphabet: {``T``, ``F``, ``*``, ``0``}. | ||||
|  | ||||
| .. method:: GEOSGeometry.touches(other) | ||||
| @@ -397,8 +397,8 @@ Topological Methods | ||||
| .. method:: GEOSGeometry.buffer(width, quadsegs=8) | ||||
|  | ||||
| Returns a :class:`GEOSGeometry` that represents all points whose distance | ||||
| from this geometry is less than or equal to the given ``width``. The optional  | ||||
| ``quadsegs`` keyword sets the number of segments used to approximate a  | ||||
| from this geometry is less than or equal to the given ``width``. The optional | ||||
| ``quadsegs`` keyword sets the number of segments used to approximate a | ||||
| quarter circle (defaults is 8). | ||||
|  | ||||
| .. method:: GEOSGeometry.difference(other) | ||||
| @@ -423,21 +423,21 @@ algorithm to the specified tolerance.  A higher tolerance value implies | ||||
| less points in the output.  If no tolerance is tolerance provided, | ||||
| it defaults to 0. | ||||
|  | ||||
| By default, this function does not preserve topology - e.g.,  | ||||
| By default, this function does not preserve topology - e.g., | ||||
| :class:`Polygon` objects can be split, collapsed into lines or disappear. | ||||
| :class:`Polygon` holes can be created or disappear, and lines can cross. | ||||
| By specifying ``preserve_topology=True``, the result will have the same | ||||
| dimension and number of components as the input, however, this is  | ||||
| significantly slower.    | ||||
| dimension and number of components as the input, however, this is | ||||
| significantly slower. | ||||
|  | ||||
| .. method:: GEOSGeometry.sym_difference(other) | ||||
|  | ||||
| Returns a :class:`GEOSGeometry` combining the points in this geometry  | ||||
| Returns a :class:`GEOSGeometry` combining the points in this geometry | ||||
| not in other, and the points in other not in this geometry. | ||||
|  | ||||
| .. method:: GEOSGeometry.union(other) | ||||
|  | ||||
| Returns a :class:`GEOSGeometry` representing all the points in this  | ||||
| Returns a :class:`GEOSGeometry` representing all the points in this | ||||
| geometry and the other. | ||||
|  | ||||
| Topological Properties | ||||
| @@ -477,7 +477,7 @@ This property returns the area of the Geometry. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.extent | ||||
|  | ||||
| This property returns the extent of this geometry as a 4-tuple,  | ||||
| This property returns the extent of this geometry as a 4-tuple, | ||||
| consisting of (xmin, ymin, xmax, ymax). | ||||
|  | ||||
| .. method:: GEOSGeometry.clone() | ||||
| @@ -492,24 +492,22 @@ Returns the distance between the closest points on this geometry and the given | ||||
| .. note:: | ||||
|  | ||||
|     GEOS distance calculations are  linear -- in other words, GEOS does not | ||||
|     perform a spherical calculation even if the SRID specifies a geographic  | ||||
|     perform a spherical calculation even if the SRID specifies a geographic | ||||
|     coordinate system. | ||||
|  | ||||
| .. attribute:: GEOSGeometry.length | ||||
|  | ||||
| Returns the length of this geometry (e.g., 0 for a :class:`Point`,  | ||||
| the length of a :class:`LineString`, or the circumference of  | ||||
| Returns the length of this geometry (e.g., 0 for a :class:`Point`, | ||||
| the length of a :class:`LineString`, or the circumference of | ||||
| a :class:`Polygon`). | ||||
|  | ||||
| .. attribute:: GEOSGeometry.prepared | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
|     Support for prepared geometries requires GEOS 3.1. | ||||
|  | ||||
| Returns a GEOS ``PreparedGeometry`` for the contents of this geometry.   | ||||
| Returns a GEOS ``PreparedGeometry`` for the contents of this geometry. | ||||
| ``PreparedGeometry`` objects are optimized for the contains, intersects, | ||||
| and covers operations.  Refer to the :ref:`prepared-geometries` documentation | ||||
| for more information. | ||||
| @@ -529,7 +527,7 @@ corresponding to the SRID of the geometry or ``None``. | ||||
|  | ||||
| Transforms the geometry according to the given coordinate transformation paramter | ||||
| (``ct``), which may be an integer SRID, spatial reference WKT string, | ||||
| a PROJ.4 string, a :class:`~django.contrib.gis.gdal.SpatialReference` object, or a  | ||||
| a PROJ.4 string, a :class:`~django.contrib.gis.gdal.SpatialReference` object, or a | ||||
| :class:`~django.contrib.gis.gdal.CoordTransform` object. By default, the geometry | ||||
| is transformed in-place and nothing is returned. However if the ``clone`` keyword | ||||
| is set, then the geometry is not modified and a transformed clone of the geometry | ||||
| @@ -611,8 +609,6 @@ is returned instead. | ||||
|  | ||||
|    .. classmethod:: from_bbox(bbox) | ||||
|  | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
|    Returns a polygon object from the given bounding-box, a 4-tuple | ||||
|    comprising (xmin, ymin, xmax, ymax). | ||||
|  | ||||
| @@ -651,11 +647,9 @@ Geometry Collections | ||||
|  | ||||
|    .. attribute:: merged | ||||
|  | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
|    Returns a :class:`LineString` representing the line merge of | ||||
|    all the components in this ``MultiLineString``. | ||||
|         | ||||
|  | ||||
|  | ||||
| ``MultiPolygon`` | ||||
| ---------------- | ||||
| @@ -673,8 +667,6 @@ Geometry Collections | ||||
|  | ||||
|    .. attribute:: cascaded_union | ||||
|  | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
|    Returns a :class:`Polygon` that is the union of all of the component | ||||
|    polygons in this collection.  The algorithm employed is significantly | ||||
|    more efficient (faster) than trying to union the geometries together | ||||
| @@ -702,13 +694,11 @@ Geometry Collections | ||||
| Prepared Geometries | ||||
| =================== | ||||
|  | ||||
| .. versionadded: 1.1 | ||||
|  | ||||
| In order to obtain a prepared geometry, just access the | ||||
| :attr:`GEOSGeometry.prepared` property.  Once you have a | ||||
| ``PreparedGeometry`` instance its spatial predicate methods, listed below, | ||||
| may be used with other ``GEOSGeometry`` objects.  An operation with a prepared | ||||
| geometry can be orders of magnitude faster -- the more complex the geometry  | ||||
| geometry can be orders of magnitude faster -- the more complex the geometry | ||||
| that is prepared, the larger the speedup in the operation.  For more information, | ||||
| please consult the `GEOS wiki page on prepared geometries <http://trac.osgeo.org/geos/wiki/PreparedGeometry>`_. | ||||
|  | ||||
| @@ -770,8 +760,6 @@ Example:: | ||||
| I/O Objects | ||||
| =========== | ||||
|  | ||||
| .. versionadded: 1.1 | ||||
|  | ||||
| Reader Objects | ||||
| -------------- | ||||
|  | ||||
| @@ -807,7 +795,7 @@ include the SRID and 3D values (in other words, EWKB). | ||||
| .. class:: WKBWriter | ||||
|  | ||||
| ``WKBWriter`` provides the most control over its output.  By default it | ||||
| returns OGC-compliant WKB when it's ``write`` method is called.  However,  | ||||
| returns OGC-compliant WKB when it's ``write`` method is called.  However, | ||||
| it has properties that allow for the creation of EWKB, a superset of the | ||||
| WKB standard that includes additional information. | ||||
|  | ||||
| @@ -925,5 +913,5 @@ location (e.g., ``/home/bob/lib/libgeos_c.so``). | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
|     The setting must be the *full* path to the **C** shared library; in  | ||||
|     The setting must be the *full* path to the **C** shared library; in | ||||
|     other words you want to use ``libgeos_c.so``, not ``libgeos.so``. | ||||
|   | ||||
| @@ -4,8 +4,6 @@ | ||||
| GeoDjango | ||||
| ========= | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. module:: django.contrib.gis | ||||
|    :synopsis: Geographic Information System (GIS) extensions for Django | ||||
|  | ||||
|   | ||||
| @@ -357,7 +357,6 @@ file:: | ||||
|  | ||||
| SpatiaLite | ||||
| ---------- | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
|   | ||||
| @@ -28,8 +28,6 @@ Settings | ||||
| ``POSTGIS_TEMPLATE`` | ||||
| ^^^^^^^^^^^^^^^^^^^^ | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| .. versionchanged:: 1.2 | ||||
|  | ||||
| This setting may be used to customize the name of the PostGIS template | ||||
| @@ -42,8 +40,6 @@ defaults to ``'template_postgis'`` (the same name used in the | ||||
| ``POSTGIS_VERSION`` | ||||
| ^^^^^^^^^^^^^^^^^^^ | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| When GeoDjango's spatial backend initializes on PostGIS, it has to perform | ||||
| a SQL query to determine the version in order to figure out what | ||||
| features are available.  Advanced users wishing to prevent this additional | ||||
| @@ -118,8 +114,6 @@ spatial database entitled ``template_postgis``. | ||||
| SpatiaLite | ||||
| ========== | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| You will need to download the `initialization SQL`__ script for SpatiaLite:: | ||||
|  | ||||
|     $ wget http://www.gaia-gis.it/spatialite/init_spatialite-2.3.zip | ||||
| @@ -138,8 +132,6 @@ Settings | ||||
| ``SPATIALITE_SQL`` | ||||
| ^^^^^^^^^^^^^^^^^^ | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| By default, the GeoDjango test runner looks for the SpatiaLite SQL in the | ||||
| same directory where it was invoked (by default the same directory where | ||||
| ``manage.py`` is located).  If you want to use a different location, then | ||||
| @@ -201,7 +193,7 @@ all of the databases in the settings file must be using one of the | ||||
|  | ||||
| .. warning:: | ||||
|  | ||||
|     Do not change the :setting:`TEST_RUNNER` setting  | ||||
|     Do not change the :setting:`TEST_RUNNER` setting | ||||
|     when running the GeoDjango tests with ``runtests.py``. | ||||
|  | ||||
| Example | ||||
|   | ||||
| @@ -68,8 +68,6 @@ You can pass in either an integer or a string representation of an integer. | ||||
| naturalday | ||||
| ---------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| For dates that are the current day or within one day, return "today", | ||||
| "tomorrow" or "yesterday", as appropriate. Otherwise, format the date using | ||||
| the passed in format string. | ||||
|   | ||||
| @@ -61,10 +61,6 @@ See :doc:`/topics/auth`. | ||||
| comments | ||||
| ======== | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    The comments application has been rewriten. See :doc:`/ref/contrib/comments/upgrade` | ||||
|    for information on howto upgrade. | ||||
|  | ||||
| A simple yet flexible comments system. See :doc:`/ref/contrib/comments/index`. | ||||
|  | ||||
| contenttypes | ||||
|   | ||||
| @@ -365,8 +365,6 @@ Pinging Google via `manage.py` | ||||
|  | ||||
| .. django-admin:: ping_google | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Once the sitemaps application is added to your project, you may also | ||||
| ping Google using the ``ping_google`` management command:: | ||||
|  | ||||
|   | ||||
| @@ -240,8 +240,6 @@ To do this, you can use the sites framework. A simple example:: | ||||
| Caching the current ``Site`` object | ||||
| =================================== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| As the current site is stored in the database, each call to | ||||
| ``Site.objects.get_current()`` could result in a database query. But Django is a | ||||
| little cleverer than that: on the first request, the current site is cached, and | ||||
| @@ -395,8 +393,6 @@ Here's how Django uses the sites framework: | ||||
|  | ||||
| .. _requestsite-objects: | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Some :doc:`django.contrib </ref/contrib/index>` applications take advantage of | ||||
| the sites framework but are architected in a way that doesn't *require* the | ||||
| sites framework to be installed in your database. (Some people don't want to, or | ||||
|   | ||||
| @@ -58,8 +58,6 @@ as any other Django backend in this respect. | ||||
| Autocommit mode | ||||
| ~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| If your application is particularly read-heavy and doesn't make many | ||||
| database writes, the overhead of a constantly open transaction can | ||||
| sometimes be noticeable. For those situations, if you're using the | ||||
| @@ -101,8 +99,6 @@ protection for multi-call operations. | ||||
| Indexes for ``varchar`` and ``text`` columns | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.1.2 | ||||
|  | ||||
| When specifying ``db_index=True`` on your model fields, Django typically | ||||
| outputs a single ``CREATE INDEX`` statement.  However, if the database type | ||||
| for the field is either ``varchar`` or ``text`` (e.g., used by ``CharField``, | ||||
| @@ -454,8 +450,6 @@ version of SQLite. | ||||
| Using newer versions of the SQLite DB-API 2.0 driver | ||||
| ---------------------------------------------------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| For versions of Python 2.5 or newer that include ``sqlite3`` in the standard | ||||
| library Django will now use a ``pysqlite2`` interface in preference to | ||||
| ``sqlite3`` if it finds one is available. | ||||
| @@ -637,8 +631,6 @@ many-to-many table would be stored in the ``indexes`` tablespace. The ``data`` | ||||
| field would also generate an index, but no tablespace for it is specified, so | ||||
| it would be stored in the model tablespace ``tables`` by default. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Use the :setting:`DEFAULT_TABLESPACE` and :setting:`DEFAULT_INDEX_TABLESPACE` | ||||
| settings to specify default values for the db_tablespace options. | ||||
| These are useful for setting a tablespace for the built-in Django apps and | ||||
|   | ||||
| @@ -88,8 +88,6 @@ cleanup | ||||
|  | ||||
| .. django-admin:: cleanup | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Can be run as a cronjob or directly to clean out old data from the database | ||||
| (only expired sessions at the moment). | ||||
|  | ||||
| @@ -98,9 +96,6 @@ compilemessages | ||||
|  | ||||
| .. django-admin:: compilemessages | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    Before 1.0 this was the "bin/compile-messages.py" command. | ||||
|  | ||||
| Compiles .po files created with ``makemessages`` to .mo files for use with | ||||
| the builtin gettext support. See :doc:`/topics/i18n/index`. | ||||
|  | ||||
| @@ -197,8 +192,6 @@ By default, ``dumpdata`` will output all data on a single line. This isn't | ||||
| easy for humans to read, so you can use the ``--indent`` option to | ||||
| pretty-print the output with a number of indentation spaces. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| The :djadminopt:`--exclude` option may be provided to prevent specific | ||||
| applications from being dumped. | ||||
|  | ||||
| @@ -207,8 +200,6 @@ applications from being dumped. | ||||
| The :djadminopt:`--exclude` option may also be provided to prevent specific | ||||
| models (specified as in the form of ``appname.ModelName``) from being dumped. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| In addition to specifying application names, you can provide a list of | ||||
| individual models, in the form of ``appname.Model``. If you specify a model | ||||
| name to ``dumpdata``, the dumped output will be restricted to that model, | ||||
| @@ -406,9 +397,6 @@ makemessages | ||||
|  | ||||
| .. django-admin:: makemessages | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    Before 1.0 this was the ``bin/make-messages.py`` command. | ||||
|  | ||||
| Runs over the entire source tree of the current directory and pulls out all | ||||
| strings marked for translation. It creates (or updates) a message file in the | ||||
| conf/locale (in the django tree) or locale (for project and application) | ||||
| @@ -963,8 +951,6 @@ testserver <fixture fixture ...> | ||||
|  | ||||
| .. django-admin:: testserver | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Runs a Django development server (as in ``runserver``) using data from the | ||||
| given fixture(s). | ||||
|  | ||||
| @@ -1067,8 +1053,6 @@ createsuperuser | ||||
|  | ||||
| .. django-admin:: createsuperuser | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| This command is only available if Django's :doc:`authentication system | ||||
| </topics/auth>` (``django.contrib.auth``) is installed. | ||||
|  | ||||
|   | ||||
| @@ -195,9 +195,6 @@ it, you can access the clean data via its ``cleaned_data`` attribute:: | ||||
|     >>> f.cleaned_data | ||||
|     {'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'} | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|     The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases. | ||||
|  | ||||
| Note that any text-based field -- such as ``CharField`` or ``EmailField`` -- | ||||
| always cleans the input into a Unicode string. We'll cover the encoding | ||||
| implications later in this document. | ||||
| @@ -680,8 +677,6 @@ by a ``Widget``:: | ||||
| Binding uploaded files to a form | ||||
| -------------------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Dealing with forms that have ``FileField`` and ``ImageField`` fields | ||||
| is a little more complicated than a normal form. | ||||
|  | ||||
|   | ||||
| @@ -230,8 +230,6 @@ fields. We've specified ``auto_id=False`` to simplify the output:: | ||||
| ``error_messages`` | ||||
| ~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. attribute:: Field.error_messages | ||||
|  | ||||
| The ``error_messages`` argument lets you override the default messages that the | ||||
| @@ -303,11 +301,6 @@ For each field, we describe the default widget used if you don't specify | ||||
|       the field has ``required=True``. | ||||
|     * Error message keys: ``required`` | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    The empty value for a ``CheckboxInput`` (and hence the standard | ||||
|    ``BooleanField``) has changed to return ``False`` instead of ``None`` in | ||||
|    the Django 1.0. | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
|     Since all ``Field`` subclasses have ``required=True`` by default, the | ||||
| @@ -411,10 +404,6 @@ If no ``input_formats`` argument is provided, the default input formats are:: | ||||
|     '%B %d %Y', '%B %d, %Y',            # 'October 25 2006', 'October 25, 2006' | ||||
|     '%d %B %Y', '%d %B, %Y',            # '25 October 2006', '25 October, 2006' | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|    The ``DateField`` previously used a ``TextInput`` widget by default. It now | ||||
|    uses a ``DateInput`` widget. | ||||
|  | ||||
| ``DateTimeField`` | ||||
| ~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| @@ -446,14 +435,9 @@ If no ``input_formats`` argument is provided, the default input formats are:: | ||||
|     '%m/%d/%y %H:%M',        # '10/25/06 14:30' | ||||
|     '%m/%d/%y',              # '10/25/06' | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    The ``DateTimeField`` used to use a ``TextInput`` widget by default. This has now changed. | ||||
|  | ||||
| ``DecimalField`` | ||||
| ~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. class:: DecimalField(**kwargs) | ||||
|  | ||||
|     * Default widget: ``TextInput`` | ||||
| @@ -506,8 +490,6 @@ given length. | ||||
| ``FileField`` | ||||
| ~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. class:: FileField(**kwargs) | ||||
|  | ||||
|     * Default widget: ``ClearableFileInput`` | ||||
| @@ -526,8 +508,6 @@ When you use a ``FileField`` in a form, you must also remember to | ||||
| ``FilePathField`` | ||||
| ~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. class:: FilePathField(**kwargs) | ||||
|  | ||||
|     * Default widget: ``Select`` | ||||
| @@ -572,8 +552,6 @@ These control the range of values permitted in the field. | ||||
| ``ImageField`` | ||||
| ~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. class:: ImageField(**kwargs) | ||||
|  | ||||
|     * Default widget: ``ClearableFileInput`` | ||||
| @@ -855,11 +833,6 @@ for ``DateField`` are used. | ||||
| If no ``input_time_formats`` argument is provided, the default input formats | ||||
| for ``TimeField`` are used. | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|    The ``SplitDateTimeField`` previously used two ``TextInput`` widgets by | ||||
|    default. The ``input_date_formats`` and ``input_time_formats`` arguments | ||||
|    are also new. | ||||
|  | ||||
| Fields which handle relationships | ||||
| --------------------------------- | ||||
|  | ||||
|   | ||||
| @@ -56,8 +56,6 @@ commonly used groups of widgets: | ||||
|  | ||||
| .. class:: DateInput | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     Date input as a simple text box: ``<input type='text' ...>`` | ||||
|  | ||||
|     Takes one optional argument: | ||||
| @@ -70,8 +68,6 @@ commonly used groups of widgets: | ||||
|  | ||||
| .. class:: DateTimeInput | ||||
|  | ||||
|     .. versionadded:: 1.0 | ||||
|  | ||||
|     Date/time input as a simple text box: ``<input type='text' ...>`` | ||||
|  | ||||
|     Takes one optional argument: | ||||
| @@ -95,9 +91,6 @@ commonly used groups of widgets: | ||||
|  | ||||
|     If no ``format`` argument is provided, the default format is ``'%H:%M:%S'``. | ||||
|  | ||||
|     .. versionchanged:: 1.1 | ||||
|        The ``format`` argument was not supported in Django 1.0. | ||||
|  | ||||
| .. class:: Textarea | ||||
|  | ||||
|     Text area: ``<textarea>...</textarea>`` | ||||
| @@ -167,9 +160,6 @@ commonly used groups of widgets: | ||||
|     Takes two optional arguments, ``date_format`` and ``time_format``, which | ||||
|     work just like the ``format`` argument for ``DateInput`` and ``TimeInput``. | ||||
|  | ||||
|     .. versionchanged:: 1.1 | ||||
|        The ``date_format`` and ``time_format`` arguments were not supported in Django 1.0. | ||||
|  | ||||
| .. class:: SelectDateWidget | ||||
|  | ||||
|     Wrapper around three select widgets: one each for month, day, and year. | ||||
|   | ||||
| @@ -93,9 +93,6 @@ If the given URL is ``None``, Django will return an ``HttpResponseGone`` (410). | ||||
|       to the URL. If ``False``, then the query string is discarded. By | ||||
|       default, ``query_string`` is ``False``. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|     The ``permanent`` keyword argument is new in Django 1.1. | ||||
|  | ||||
| .. versionadded:: 1.3 | ||||
|     The ``query_string`` keyword argument is new in Django 1.3. | ||||
|  | ||||
| @@ -184,8 +181,6 @@ a date in the *future* are not included unless you set ``allow_future`` to | ||||
|       specified in ``date_field`` is greater than the current date/time. By | ||||
|       default, this is ``False``. | ||||
|  | ||||
|     .. versionadded:: 1.0 | ||||
|  | ||||
|     * ``template_object_name``: Designates the name of the template variable | ||||
|       to use in the template context. By default, this is ``'latest'``. | ||||
|  | ||||
| @@ -210,9 +205,6 @@ In addition to ``extra_context``, the template's context will be: | ||||
|       ``datetime.datetime`` objects. These are ordered in reverse. This is | ||||
|       equivalent to ``queryset.dates(date_field, 'year')[::-1]``. | ||||
|  | ||||
|     .. versionchanged:: 1.0 | ||||
|        The behaviour depending on ``template_object_name`` is new in this version. | ||||
|  | ||||
|     * ``latest``: The ``num_latest`` objects in the system, ordered descending | ||||
|       by ``date_field``. For example, if ``num_latest`` is ``10``, then | ||||
|       ``latest`` will be a list of the latest 10 objects in ``queryset``. | ||||
| @@ -729,9 +721,6 @@ If ``template_name`` isn't specified, this view will use the template | ||||
|  | ||||
| **Template context:** | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    The ``paginator`` and ``page_obj`` context variables are new. | ||||
|  | ||||
| In addition to ``extra_context``, the template's context will be: | ||||
|  | ||||
|     * ``object_list``: The list of objects. This variable's name depends on the | ||||
| @@ -775,8 +764,6 @@ represented as page ``1``. | ||||
| For more on pagination, read the :doc:`pagination documentation | ||||
| </topics/pagination>`. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| As a special case, you are also permitted to use ``last`` as a value for | ||||
| ``page``:: | ||||
|  | ||||
| @@ -861,12 +848,6 @@ Create/update/delete generic views | ||||
| The ``django.views.generic.create_update`` module contains a set of functions | ||||
| for creating, editing and deleting objects. | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|  | ||||
| ``django.views.generic.create_update.create_object`` and | ||||
| ``django.views.generic.create_update.update_object`` now use the new :doc:`forms | ||||
| library </topics/forms/index>` to build and display the form. | ||||
|  | ||||
| ``django.views.generic.create_update.create_object`` | ||||
| ---------------------------------------------------- | ||||
|  | ||||
|   | ||||
| @@ -52,11 +52,6 @@ Adds a few conveniences for perfectionists: | ||||
|       you don't have a valid URL pattern for ``foo.com/bar`` but *do* have a | ||||
|       valid pattern for ``foo.com/bar/``. | ||||
|  | ||||
|       .. versionchanged:: 1.0 | ||||
|          The behavior of :setting:`APPEND_SLASH` has changed slightly in this | ||||
|          version. It didn't used to check whether the pattern was matched in | ||||
|          the URLconf. | ||||
|  | ||||
|       If :setting:`PREPEND_WWW` is ``True``, URLs that lack a leading "www." | ||||
|       will be redirected to the same URL with a leading "www." | ||||
|  | ||||
| @@ -123,8 +118,6 @@ Reverse proxy middleware | ||||
|  | ||||
| .. class:: SetRemoteAddrFromForwardedFor | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|  | ||||
| This middleware was removed in Django 1.1. See :ref:`the release notes | ||||
| <removed-setremoteaddrfromforwardedfor-middleware>` for details. | ||||
|  | ||||
| @@ -186,8 +179,6 @@ CSRF protection middleware | ||||
|  | ||||
| .. class:: CsrfMiddleware | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Adds protection against Cross Site Request Forgeries by adding hidden form | ||||
| fields to POST forms and checking requests for the correct value. See the | ||||
| :doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`. | ||||
|   | ||||
| @@ -173,8 +173,6 @@ If ``True``, djadmin:`django-admin.py sqlindexes <sqlindexes>` will output a | ||||
|  | ||||
| .. attribute:: Field.db_tablespace | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| The name of the database tablespace to use for this field's index, if this field | ||||
| is indexed. The default is the project's :setting:`DEFAULT_INDEX_TABLESPACE` | ||||
| setting, if set, or the :attr:`~Field.db_tablespace` of the model, if any. If | ||||
| @@ -432,8 +430,6 @@ JavaScript shortcuts. | ||||
| ``DecimalField`` | ||||
| ---------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. class:: DecimalField(max_digits=None, decimal_places=None, [**options]) | ||||
|  | ||||
| A fixed-precision decimal number, represented in Python by a | ||||
| @@ -489,8 +485,6 @@ Has one **required** argument: | ||||
|     date/time of the file upload (so that uploaded files don't fill up the given | ||||
|     directory). | ||||
|  | ||||
|     .. versionchanged:: 1.0 | ||||
|  | ||||
|     This may also be a callable, such as a function, which will be called to | ||||
|     obtain the upload path, including the filename. This callable must be able | ||||
|     to accept two arguments, and return a Unix-style path (with forward slashes) | ||||
| @@ -519,8 +513,6 @@ Also has one optional argument: | ||||
|  | ||||
| .. attribute:: FileField.storage | ||||
|  | ||||
|     .. versionadded:: 1.0 | ||||
|  | ||||
|     Optional. A storage object, which handles the storage and retrieval of your | ||||
|     files. See :doc:`/topics/files` for details on how to provide this object. | ||||
|  | ||||
| @@ -567,9 +559,6 @@ without validation, to a directory that's within your Web server's document | ||||
| root, then somebody could upload a CGI or PHP script and execute that script by | ||||
| visiting its URL on your site. Don't allow that. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    The ``max_length`` argument was added in this version. | ||||
|  | ||||
| By default, :class:`FileField` instances are | ||||
| created as ``varchar(100)`` columns in your database. As with other fields, you | ||||
| can change the maximum length using the :attr:`~CharField.max_length` argument. | ||||
| @@ -652,9 +641,6 @@ base filename, not the full path. So, this example:: | ||||
| because the :attr:`~FilePathField.match` applies to the base filename | ||||
| (``foo.gif`` and ``bar.gif``). | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    The ``max_length`` argument was added in this version. | ||||
|  | ||||
| By default, :class:`FilePathField` instances are | ||||
| created as ``varchar(100)`` columns in your database. As with other fields, you | ||||
| can change the maximum length using the :attr:`~CharField.max_length` argument. | ||||
| @@ -664,8 +650,6 @@ can change the maximum length using the :attr:`~CharField.max_length` argument. | ||||
|  | ||||
| .. class:: FloatField([**options]) | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|  | ||||
| A floating-point number represented in Python by a ``float`` instance. | ||||
|  | ||||
| The admin represents this as an ``<input type="text">`` (a single-line input). | ||||
| @@ -699,9 +683,6 @@ Requires the `Python Imaging Library`_. | ||||
|  | ||||
| .. _Python Imaging Library: http://www.pythonware.com/products/pil/ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    The ``max_length`` argument was added in this version. | ||||
|  | ||||
| By default, :class:`ImageField` instances are created as ``varchar(100)`` | ||||
| columns in your database. As with other fields, you can change the maximum | ||||
| length using the :attr:`~CharField.max_length` argument. | ||||
| @@ -874,8 +855,6 @@ you can use the name of the model, rather than the model object itself:: | ||||
|     class Manufacturer(models.Model): | ||||
|         # ... | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| To refer to models defined in another application, you can explicitly specify | ||||
| a model with the full application label. For example, if the ``Manufacturer`` | ||||
| model above is defined in another application called ``production``, you'd | ||||
|   | ||||
| @@ -133,9 +133,6 @@ To save an object back to the database, call ``save()``: | ||||
|  | ||||
| .. method:: Model.save([force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS]) | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    The ``force_insert`` and ``force_update`` arguments were added. | ||||
|  | ||||
| .. versionadded:: 1.2 | ||||
|    The ``using`` argument was added. | ||||
|  | ||||
| @@ -168,8 +165,6 @@ documentation for ``AutoField`` for more details. | ||||
| The ``pk`` property | ||||
| ~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. attribute:: Model.pk | ||||
|  | ||||
| Regardless of whether you define a primary key field yourself, or let Django | ||||
| @@ -278,8 +273,6 @@ auto-primary-key values`_ above and `Forcing an INSERT or UPDATE`_ below. | ||||
| Forcing an INSERT or UPDATE | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| In some rare circumstances, it's necessary to be able to force the ``save()`` | ||||
| method to perform an SQL ``INSERT`` and not fall back to doing an ``UPDATE``. | ||||
| Or vice-versa: update, if possible, but not insert a new row. In these cases | ||||
|   | ||||
| @@ -65,8 +65,6 @@ Django quotes column and table names behind the scenes. | ||||
|  | ||||
| .. attribute:: Options.db_tablespace | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| The name of the database tablespace to use for the model. If the backend doesn't | ||||
| support tablespaces, this option is ignored. | ||||
|  | ||||
| @@ -90,8 +88,6 @@ See the docs for :meth:`~django.db.models.QuerySet.latest` for more. | ||||
|  | ||||
| .. attribute:: Options.managed | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Defaults to ``True``, meaning Django will create the appropriate database | ||||
| tables in :djadmin:`syncdb` and remove them as part of a :djadmin:`reset` | ||||
| management command. That is, Django *manages* the database tables' lifecycles. | ||||
| @@ -219,8 +215,6 @@ human_readable_permission_name)``. | ||||
|  | ||||
| .. attribute:: Options.proxy | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| If set to ``True``, a model which subclasses another model will be treated as | ||||
| a :ref:`proxy model <proxy-models>`. | ||||
|  | ||||
| @@ -238,8 +232,6 @@ It's used in the Django admin and is enforced at the database level (i.e., the | ||||
| appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE`` | ||||
| statement). | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| For convenience, unique_together can be a single list when dealing with a single | ||||
| set of fields:: | ||||
|  | ||||
|   | ||||
| @@ -186,8 +186,6 @@ annotate | ||||
|  | ||||
| .. method:: annotate(*args, **kwargs) | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Annotates each object in the ``QuerySet`` with the provided list of | ||||
| aggregate values (averages, sums, etc) that have been computed over | ||||
| the objects that are related to the objects in the ``QuerySet``. | ||||
| @@ -279,13 +277,6 @@ ordering piece of data for each of the main items you are selecting, the | ||||
| ordering may well be exactly what you want to do. Use ordering on multi-valued | ||||
| fields with care and make sure the results are what you expect. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| The syntax for ordering across related models has changed. See the `Django 0.96 | ||||
| documentation`_ for the old behaviour. | ||||
|  | ||||
| .. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield | ||||
|  | ||||
| There's no way to specify whether ordering should be case sensitive. With | ||||
| respect to case-sensitivity, Django will order results however your database | ||||
| backend normally orders them. | ||||
| @@ -293,8 +284,6 @@ backend normally orders them. | ||||
| If you don't want any ordering to be applied to a query, not even the default | ||||
| ordering, call ``order_by()`` with no parameters. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| You can tell if a query is ordered or not by checking the | ||||
| :attr:`QuerySet.ordered` attribute, which will be ``True`` if the | ||||
| ``QuerySet`` has been ordered in any way. | ||||
| @@ -304,8 +293,6 @@ reverse | ||||
|  | ||||
| .. method:: reverse() | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Use the ``reverse()`` method to reverse the order in which a queryset's | ||||
| elements are returned. Calling ``reverse()`` a second time restores the | ||||
| ordering back to the normal direction. | ||||
| @@ -429,11 +416,6 @@ A few subtleties that are worth mentioning: | ||||
|       if the ``extra()`` clause is used after the ``values()``, the | ||||
|       fields added by the select will be included automatically. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Previously, it was not possible to pass ``blog_id`` to ``values()`` in the above | ||||
| example, only ``blog``. | ||||
|  | ||||
| A ``ValuesQuerySet`` is useful when you know you're only going to need values | ||||
| from a small number of the available fields and you won't need the | ||||
| functionality of a model instance object. It's more efficient to select only | ||||
| @@ -478,8 +460,6 @@ values_list | ||||
|  | ||||
| .. method:: values_list(*fields) | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| This is similar to ``values()`` except that instead of returning dictionaries, | ||||
| it returns tuples when iterated over. Each tuple contains the value from the | ||||
| respective field passed into the ``values_list()`` call -- so the first item is | ||||
| @@ -544,8 +524,6 @@ none | ||||
|  | ||||
| .. method:: none() | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Returns an ``EmptyQuerySet`` -- a ``QuerySet`` that always evaluates to | ||||
| an empty list. This can be used in cases where you know that you should | ||||
| return an empty result set and your caller is expecting a ``QuerySet`` | ||||
| @@ -561,8 +539,6 @@ all | ||||
|  | ||||
| .. method:: all() | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Returns a *copy* of the current ``QuerySet`` (or ``QuerySet`` subclass you | ||||
| pass in). This can be useful in some situations where you might want to pass | ||||
| in either a model manager or a ``QuerySet`` and do further filtering on the | ||||
| @@ -676,11 +652,6 @@ call). It's an error to use both a list of fields and the ``depth`` | ||||
| parameter in the same ``select_related()`` call, since they are | ||||
| conflicting options. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Both the ``depth`` argument and the ability to specify field names in the call | ||||
| to ``select_related()`` are new in Django version 1.0. | ||||
|  | ||||
| .. versionchanged:: 1.2 | ||||
|  | ||||
| You can also refer to the reverse direction of a ``OneToOneFields`` in | ||||
| @@ -753,8 +724,6 @@ of the arguments is required, but you should use at least one of them. | ||||
|         some database backends, such as some MySQL versions, don't support | ||||
|         subqueries. | ||||
|  | ||||
|         .. versionadded:: 1.0 | ||||
|  | ||||
|         In some rare cases, you might wish to pass parameters to the SQL fragments | ||||
|         in ``extra(select=...)``. For this purpose, use the ``select_params`` | ||||
|         parameter. Since ``select_params`` is a sequence and the ``select`` | ||||
| @@ -860,8 +829,6 @@ defer | ||||
|  | ||||
| .. method:: defer(*fields) | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| In some complex data-modeling situations, your models might contain a lot of | ||||
| fields, some of which could contain a lot of data (for example, text fields), | ||||
| or require expensive processing to convert them to Python objects. If you are | ||||
| @@ -922,8 +889,6 @@ only | ||||
|  | ||||
| .. method:: only(*fields) | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| The ``only()`` method is more or less the opposite of ``defer()``. You | ||||
| call it with the fields that should *not* be deferred when retrieving a model. | ||||
| If you have a model where almost all the fields need to be deferred, using | ||||
| @@ -1198,8 +1163,6 @@ aggregate | ||||
|  | ||||
| .. method:: aggregate(*args, **kwargs) | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Returns a dictionary of aggregate values (averages, sums, etc) calculated | ||||
| over the ``QuerySet``. Each argument to ``aggregate()`` specifies | ||||
| a value that will be included in the dictionary that is returned. | ||||
| @@ -1253,7 +1216,7 @@ the number of rows affected. The ``update()`` method is applied instantly and | ||||
| the only restriction on the :class:`QuerySet` that is updated is that it can | ||||
| only update columns in the model's main table. Filtering based on related | ||||
| fields is still possible. You cannot call ``update()`` on a | ||||
| :class:`QuerySet` that has had a slice taken or can otherwise no longer be  | ||||
| :class:`QuerySet` that has had a slice taken or can otherwise no longer be | ||||
| filtered. | ||||
|  | ||||
| For example, if you wanted to update all the entries in a particular blog | ||||
| @@ -1334,12 +1297,6 @@ SQL equivalents:: | ||||
|     SELECT ... WHERE id = 14; | ||||
|     SELECT ... WHERE id IS NULL; | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    The semantics of ``id__exact=None`` have changed in Django 1.0. Previously, | ||||
|    it was (intentionally) converted to ``WHERE id = NULL`` at the SQL level, | ||||
|    which would never match anything. It has now been changed to behave the | ||||
|    same as ``id__isnull=True``. | ||||
|  | ||||
| .. admonition:: MySQL comparisons | ||||
|  | ||||
|     In MySQL, a database table's "collation" setting determines whether | ||||
| @@ -1446,10 +1403,6 @@ The above code fragment could also be written as follows:: | ||||
|     inner_q = Blog.objects.filter(name__contains='Cheddar').values('pk').query | ||||
|     entries = Entry.objects.filter(blog__in=inner_q) | ||||
|  | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|     In Django 1.0, only the latter piece of code is valid. | ||||
|  | ||||
| This second form is a bit less readable and unnatural to write, since it | ||||
| accesses the internal ``query`` attribute and requires a ``ValuesQuerySet``. | ||||
| If your code doesn't require compatibility with Django 1.0, use the first | ||||
| @@ -1687,8 +1640,6 @@ such as January 3, July 3, etc. | ||||
| week_day | ||||
| ~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| For date/datetime fields, a 'day of the week' match. | ||||
|  | ||||
| Takes an integer value representing the day of week from 1 (Sunday) to 7 | ||||
| @@ -1748,8 +1699,6 @@ full text searches. `See the MySQL documentation for additional details. | ||||
| regex | ||||
| ~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Case-sensitive regular expression match. | ||||
|  | ||||
| The regular expression syntax is that of the database backend in use. | ||||
| @@ -1779,8 +1728,6 @@ regular expression syntax is recommended. | ||||
| iregex | ||||
| ~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Case-insensitive regular expression match. | ||||
|  | ||||
| Example:: | ||||
| @@ -1802,8 +1749,6 @@ SQL equivalents:: | ||||
| Aggregation Functions | ||||
| --------------------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Django provides the following aggregation functions in the | ||||
| ``django.db.models`` module. For details on how to use these | ||||
| aggregate functions, see | ||||
|   | ||||
| @@ -117,16 +117,6 @@ All attributes except ``session`` should be considered read-only. | ||||
|     ``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank | ||||
|     dictionary-like object. | ||||
|  | ||||
|     .. versionchanged:: 1.0 | ||||
|  | ||||
|     In previous versions of Django, ``request.FILES`` contained simple ``dict`` | ||||
|     objects representing uploaded files. This is no longer true -- files are | ||||
|     represented by :class:`UploadedFile` objects. | ||||
|  | ||||
|     These :class:`UploadedFile` objects will emulate the old-style ``dict`` | ||||
|     interface, but this is deprecated and will be removed in the next release | ||||
|     of Django. | ||||
|  | ||||
| .. attribute:: HttpRequest.META | ||||
|  | ||||
|     A standard Python dictionary containing all available HTTP headers. | ||||
| @@ -522,8 +512,6 @@ To set or remove a header in your response, treat it like a dictionary:: | ||||
| Note that unlike a dictionary, ``del`` doesn't raise ``KeyError`` if the header | ||||
| doesn't exist. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| HTTP headers cannot contain newlines. An attempt to set a header containing a | ||||
| newline character (CR or LF) will raise ``BadHeaderError`` | ||||
|  | ||||
|   | ||||
| @@ -699,8 +699,6 @@ Never deploy a site into production with ``DEBUG`` turned on. | ||||
| DEBUG_PROPAGATE_EXCEPTIONS | ||||
| -------------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``False`` | ||||
|  | ||||
| If set to True, Django's normal exception handling of view functions | ||||
| @@ -766,8 +764,6 @@ site manager(s). | ||||
| DEFAULT_INDEX_TABLESPACE | ||||
| ------------------------ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``''`` (Empty string) | ||||
|  | ||||
| Default tablespace to use for indexes on fields that don't specify | ||||
| @@ -778,8 +774,6 @@ one, if the backend supports it. | ||||
| DEFAULT_TABLESPACE | ||||
| ------------------ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``''`` (Empty string) | ||||
|  | ||||
| Default tablespace to use for models that don't specify one, if the | ||||
| @@ -882,8 +876,6 @@ trailing space. | ||||
| EMAIL_USE_TLS | ||||
| ------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``False`` | ||||
|  | ||||
| Whether to use a TLS (secure) connection when talking to the SMTP server. | ||||
| @@ -893,8 +885,6 @@ Whether to use a TLS (secure) connection when talking to the SMTP server. | ||||
| FILE_CHARSET | ||||
| ------------ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``'utf-8'`` | ||||
|  | ||||
| The character encoding used to decode any files read from disk. This includes | ||||
| @@ -905,8 +895,6 @@ template files and initial SQL data files. | ||||
| FILE_UPLOAD_HANDLERS | ||||
| -------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default:: | ||||
|  | ||||
|     ("django.core.files.uploadhandler.MemoryFileUploadHandler", | ||||
| @@ -919,8 +907,6 @@ A tuple of handlers to use for uploading. See :doc:`/topics/files` for details. | ||||
| FILE_UPLOAD_MAX_MEMORY_SIZE | ||||
| --------------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``2621440`` (i.e. 2.5 MB). | ||||
|  | ||||
| The maximum size (in bytes) that an upload will be before it gets streamed to | ||||
| @@ -959,8 +945,6 @@ system's standard umask. | ||||
| FILE_UPLOAD_TEMP_DIR | ||||
| -------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``None`` | ||||
|  | ||||
| The directory to store data temporarily while uploading files. If ``None``, | ||||
| @@ -1106,8 +1090,6 @@ standard :term:`language format<language code>`. For example, U.S. English is | ||||
| LANGUAGE_COOKIE_NAME | ||||
| -------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``'django_language'`` | ||||
|  | ||||
| The name of the cookie to use for the language cookie. This can be whatever you | ||||
| @@ -1206,8 +1188,6 @@ configuration process will be skipped. | ||||
| LOGIN_REDIRECT_URL | ||||
| ------------------ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``'/accounts/profile/'`` | ||||
|  | ||||
| The URL where requests are redirected after login when the | ||||
| @@ -1221,8 +1201,6 @@ decorator, for example. | ||||
| LOGIN_URL | ||||
| --------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``'/accounts/login/'`` | ||||
|  | ||||
| The URL where requests are redirected for login, especially when using the | ||||
| @@ -1233,8 +1211,6 @@ The URL where requests are redirected for login, especially when using the | ||||
| LOGOUT_URL | ||||
| ---------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``'/accounts/logout/'`` | ||||
|  | ||||
| LOGIN_URL counterpart. | ||||
| @@ -1531,8 +1507,6 @@ should be different from ``LANGUAGE_COOKIE_NAME``). See the :doc:`/topics/http/s | ||||
| SESSION_COOKIE_PATH | ||||
| ------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``'/'`` | ||||
|  | ||||
| The path set on the session cookie. This should either match the URL path of your | ||||
| @@ -1559,11 +1533,6 @@ See the :doc:`/topics/http/sessions`. | ||||
| SESSION_ENGINE | ||||
| -------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|    The ``cached_db`` backend was added | ||||
|  | ||||
| Default: ``django.contrib.sessions.backends.db`` | ||||
|  | ||||
| Controls where Django stores session data. Valid values are: | ||||
| @@ -1590,8 +1559,6 @@ See the :doc:`/topics/http/sessions`. | ||||
| SESSION_FILE_PATH | ||||
| ----------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``None`` | ||||
|  | ||||
| If you're using file-based session storage, this sets the directory in | ||||
|   | ||||
| @@ -474,8 +474,6 @@ connection_created | ||||
| .. data:: django.db.backends.signals.connection_created | ||||
|    :module: | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| .. versionchanged:: 1.2 | ||||
|    The connection argument was added | ||||
|  | ||||
|   | ||||
| @@ -459,8 +459,6 @@ See :doc:`/topics/i18n/index` for more. | ||||
| django.core.context_processors.media | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every | ||||
| ``RequestContext`` will contain a variable ``MEDIA_URL``, providing the | ||||
| value of the :setting:`MEDIA_URL` setting. | ||||
|   | ||||
| @@ -19,8 +19,6 @@ Built-in tag reference | ||||
| autoescape | ||||
| ~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Control the current auto-escaping behavior. This tag takes either ``on`` or | ||||
| ``off`` as an argument and that determines whether auto-escaping is in effect | ||||
| inside the block. The block is closed with an ``endautoescape`` ending tag. | ||||
| @@ -60,8 +58,6 @@ Ignore everything between ``{% comment %}`` and ``{% endcomment %}`` | ||||
| csrf_token | ||||
| ~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.1.2 | ||||
|  | ||||
| In the Django 1.1.X series, this is a no-op tag that returns an empty string for | ||||
| future compatibility purposes.  In Django 1.2 and later, it is used for CSRF | ||||
| protection, as described in the documentation for :doc:`Cross Site Request | ||||
| @@ -72,8 +68,7 @@ Forgeries </ref/contrib/csrf>`. | ||||
| cycle | ||||
| ~~~~~ | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|     Cycle among the given strings or variables each time this tag is encountered. | ||||
| Cycle among the given strings or variables each time this tag is encountered. | ||||
|  | ||||
| Within a loop, cycles among the given strings each time through the | ||||
| loop:: | ||||
| @@ -259,8 +254,6 @@ provided in ``athlete_list``:: | ||||
|  | ||||
| You can loop over a list in reverse by using ``{% for obj in list reversed %}``. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If you need to loop over a list of lists, you can unpack the values | ||||
| in each sub-list into individual variables. For example, if your context | ||||
| contains a list of (x,y) coordinates called ``points``, you could use the | ||||
| @@ -298,8 +291,6 @@ The for loop sets a number of variables available within the loop: | ||||
| for ... empty | ||||
| ^^^^^^^^^^^^^ | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| The ``for`` tag can take an optional ``{% empty %}`` clause that will be | ||||
| displayed if the given array is empty or could not be found:: | ||||
|  | ||||
| @@ -954,8 +945,6 @@ such as this: | ||||
|  | ||||
| The template tag will output the string ``/clients/client/123/``. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If you're using :ref:`named URL patterns <naming-url-patterns>`, you can | ||||
| refer to the name of the pattern in the ``url`` tag instead of using the | ||||
| path to the view. | ||||
| @@ -964,8 +953,6 @@ Note that if the URL you're reversing doesn't exist, you'll get an | ||||
| :exc:`NoReverseMatch` exception raised, which will cause your site to display an | ||||
| error page. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If you'd like to retrieve a URL without displaying it, you can use a slightly | ||||
| different call:: | ||||
|  | ||||
| @@ -982,8 +969,6 @@ missing. In practice you'll use this to link to views that are optional:: | ||||
|       <a href="{{ the_url }}">Link to optional stuff</a> | ||||
|     {% endif %} | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| If you'd like to retrieve a namespaced URL, specify the fully qualified name:: | ||||
|  | ||||
|     {% url myapp:view-name %} | ||||
| @@ -1054,8 +1039,6 @@ which is rounded up to 88). | ||||
| with | ||||
| ~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. versionchanged:: 1.3 | ||||
|    New keyword argument format and multiple variable assignments. | ||||
|  | ||||
| @@ -1390,18 +1373,11 @@ applied to the result will only result in one round of escaping being done. So | ||||
| it is safe to use this function even in auto-escaping environments. If you want | ||||
| multiple escaping passes to be applied, use the ``force_escape`` filter. | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|     Due to auto-escaping, the behavior of this filter has changed slightly. | ||||
|     The replacements are only made once, after | ||||
|     all other filters are applied -- including filters before and after it. | ||||
|  | ||||
| .. templatefilter:: escapejs | ||||
|  | ||||
| escapejs | ||||
| ~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Escapes characters for use in JavaScript strings. This does *not* make the | ||||
| string safe for use in HTML, but does protect you from syntax errors when using | ||||
| templates to generate JavaScript/JSON. | ||||
| @@ -1445,8 +1421,9 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be ``'a'``. | ||||
| fix_ampersands | ||||
| ~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|     This is rarely useful as ampersands are now automatically escaped. See escape_ for more information. | ||||
| ..note:: | ||||
|  | ||||
|     This is rarely useful as ampersands are automatically escaped. See escape_ for more information. | ||||
|  | ||||
| Replaces ampersands with ``&`` entities. | ||||
|  | ||||
| @@ -1503,8 +1480,6 @@ with an argument of ``-1``. | ||||
| force_escape | ||||
| ~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Applies HTML escaping to a string (see the ``escape`` filter for details). | ||||
| This filter is applied *immediately* and returns a new, escaped string. This | ||||
| is useful in the rare cases where you need multiple escaping or want to apply | ||||
| @@ -1564,8 +1539,6 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be the string | ||||
| last | ||||
| ~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Returns the last item in a list. | ||||
|  | ||||
| For example:: | ||||
| @@ -2035,9 +2008,6 @@ unordered_list | ||||
| Recursively takes a self-nested list and returns an HTML unordered list -- | ||||
| WITHOUT opening and closing <ul> tags. | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    The format accepted by ``unordered_list`` has changed to be easier to understand. | ||||
|  | ||||
| The list is assumed to be in the proper format. For example, if ``var`` contains | ||||
| ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then | ||||
| ``{{ var|unordered_list }}`` would return:: | ||||
| @@ -2054,7 +2024,7 @@ The list is assumed to be in the proper format. For example, if ``var`` contains | ||||
|     </ul> | ||||
|     </li> | ||||
|  | ||||
| Note: the previous more restrictive and verbose format is still supported: | ||||
| Note: An older, more restrictive and verbose input format is also supported: | ||||
| ``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``, | ||||
|  | ||||
| .. templatefilter:: upper | ||||
|   | ||||
| @@ -2,8 +2,6 @@ | ||||
| Unicode data | ||||
| ============ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Django natively supports Unicode data everywhere. Providing your database can | ||||
| somehow store the data, you can safely pass around Unicode strings to | ||||
| templates, models and the database. | ||||
|   | ||||
| @@ -191,8 +191,6 @@ Methods | ||||
|  | ||||
|     .. method:: models.User.set_unusable_password() | ||||
|  | ||||
|         .. versionadded:: 1.0 | ||||
|  | ||||
|         Marks the user as having no password set.  This isn't the same as | ||||
|         having a blank string for a password. | ||||
|         :meth:`~django.contrib.auth.models.User.check_password()` for this user | ||||
| @@ -204,8 +202,6 @@ Methods | ||||
|  | ||||
|     .. method:: models.User.has_usable_password() | ||||
|  | ||||
|         .. versionadded:: 1.0 | ||||
|  | ||||
|         Returns ``False`` if | ||||
|         :meth:`~django.contrib.auth.models.User.set_unusable_password()` has | ||||
|         been called for this user. | ||||
| @@ -396,9 +392,6 @@ to salt the raw password to create the hash. Note that the ``crypt`` method is | ||||
| only supported on platforms that have the standard Python ``crypt`` module | ||||
| available. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|     Support for the ``crypt`` module is new in Django 1.0. | ||||
|  | ||||
| For example:: | ||||
|  | ||||
|     sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 | ||||
| @@ -451,9 +444,6 @@ they're used by Web requests, as explained in the next section. | ||||
| Creating superusers | ||||
| ------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    The ``manage.py createsuperuser`` command is new. | ||||
|  | ||||
| :djadmin:`manage.py syncdb <syncdb>` prompts you to create a superuser the | ||||
| first time you run it after adding ``'django.contrib.auth'`` to your | ||||
| :setting:`INSTALLED_APPS`. If you need to create a superuser at a later date, | ||||
| @@ -654,9 +644,6 @@ How to log a user out | ||||
|     Note that :func:`~django.contrib.auth.logout()` doesn't throw any errors if | ||||
|     the user wasn't logged in. | ||||
|  | ||||
|     .. versionchanged:: 1.0 | ||||
|        Calling ``logout()`` now cleans session data. | ||||
|  | ||||
|     When you call :func:`~django.contrib.auth.logout()`, the session data for | ||||
|     the current request is completely cleaned out. All existing data is | ||||
|     removed. This is to prevent another person from using the same Web browser | ||||
|   | ||||
| @@ -317,8 +317,6 @@ activate dummy caching, set :setting:`BACKEND <CACHES-BACKEND>` like so:: | ||||
| Using a custom cache backend | ||||
| ---------------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| While Django includes support for a number of cache backends out-of-the-box, | ||||
| sometimes you might want to use a customized cache backend. To use an external | ||||
| cache backend with Django, use the Python import path as the | ||||
| @@ -416,10 +414,6 @@ arguments. | ||||
| The per-site cache | ||||
| ================== | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|     (previous versions of Django only provided a single ``CacheMiddleware`` instead | ||||
|     of the two pieces described below). | ||||
|  | ||||
| Once the cache is set up, the simplest way to use caching is to cache your | ||||
| entire site. You'll need to add | ||||
| ``'django.middleware.cache.UpdateCacheMiddleware'`` and | ||||
| @@ -473,8 +467,6 @@ Additionally, the cache middleware automatically sets a few headers in each | ||||
|  | ||||
| See :doc:`/topics/http/middleware` for more on middleware. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in | ||||
| its ``Cache-Control`` header) then the page will be cached until the expiry | ||||
| time, rather than :setting:`CACHE_MIDDLEWARE_SECONDS`. Using the decorators in | ||||
| @@ -586,8 +578,6 @@ URLconf. | ||||
| Template fragment caching | ||||
| ========================= | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If you're after even more control, you can also cache template fragments using | ||||
| the ``cache`` template tag. To give your template access to this tag, put | ||||
| ``{% load cache %}`` near the top of your template. | ||||
| @@ -705,8 +695,6 @@ return if the object doesn't exist in the cache:: | ||||
|     >>> cache.get('my_key', 'has expired') | ||||
|     'has expired' | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| To add a key only if it doesn't already exist, use the ``add()`` method. | ||||
| It takes the same parameters as ``set()``, but it will not attempt to | ||||
| update the cache if the key specified is already present:: | ||||
| @@ -761,8 +749,6 @@ from the cache, not just the keys set by your application. :: | ||||
|  | ||||
|     >>> cache.clear() | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| You can also increment or decrement a key that already exists using the | ||||
| ``incr()`` or ``decr()`` methods, respectively. By default, the existing cache | ||||
| value will incremented or decremented by 1. Other increment/decrement values | ||||
|   | ||||
| @@ -2,8 +2,6 @@ | ||||
| Conditional View Processing | ||||
| =========================== | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| HTTP clients can send a number of headers to tell the server about copies of a | ||||
| resource that they have already seen. This is commonly used when retrieving a | ||||
| Web page (using an HTTP ``GET`` request) to avoid sending all the data for | ||||
|   | ||||
| @@ -2,8 +2,6 @@ | ||||
| Aggregation | ||||
| =========== | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| .. currentmodule:: django.db.models | ||||
|  | ||||
| The topic guide on :doc:`Django's database-abstraction API </topics/db/queries>` | ||||
|   | ||||
| @@ -387,8 +387,6 @@ work; all are optional. | ||||
| Extra fields on many-to-many relationships | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| When you're only dealing with simple many-to-many relationships such as | ||||
| mixing and matching pizzas and toppings, a standard :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes | ||||
| you may need to associate data with the relationship between two models. | ||||
| @@ -553,8 +551,6 @@ can be made; see :ref:`the model field reference <ref-onetoone>` for details. | ||||
|  | ||||
| .. _One-to-one relationship model example: http://www.djangoproject.com/documentation/models/one_to_one/ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| :class:`~django.db.models.OneToOneField` fields also accept one optional argument | ||||
| described in the :ref:`model field reference <ref-onetoone>`. | ||||
|  | ||||
| @@ -606,8 +602,6 @@ particular database engine. | ||||
| Custom field types | ||||
| ------------------ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If one of the existing model fields cannot be used to fit your purposes, or if | ||||
| you wish to take advantage of some less common database column types, you can | ||||
| create your own field class. Full coverage of creating your own fields is | ||||
| @@ -769,8 +763,6 @@ on :doc:`using raw SQL</topics/db/sql>`. | ||||
| Model inheritance | ||||
| ================= | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Model inheritance in Django works almost identically to the way normal | ||||
| class inheritance works in Python. The only decision you have to make | ||||
| is whether you want the parent models to be models in their own right | ||||
| @@ -1026,8 +1018,6 @@ to indicate that your field is the link back to the parent class. | ||||
| Proxy models | ||||
| ------------ | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| When using :ref:`multi-table inheritance <multi-table-inheritance>`, a new | ||||
| database table is created for each subclass of a model. This is usually the | ||||
| desired behavior, since the subclass needs a place to store any additional | ||||
|   | ||||
| @@ -475,8 +475,6 @@ those latter objects, you could write:: | ||||
| Spanning multi-valued relationships | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| When you are filtering an object based on a ``ManyToManyField`` or a reverse | ||||
| ``ForeignKey``, there are two different sorts of filter you may be | ||||
| interested in. Consider the ``Blog``/``Entry`` relationship (``Blog`` to | ||||
| @@ -532,8 +530,6 @@ filtering on different linked objects. | ||||
| Filters can reference fields on the model | ||||
| ----------------------------------------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| In the examples given so far, we have constructed filters that compare | ||||
| the value of a model field with a constant. But what if you want to compare | ||||
| the value of a model field with another field on the same model? | ||||
| @@ -818,8 +814,6 @@ complete query set:: | ||||
| Updating multiple objects at once | ||||
| ================================= | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Sometimes you want to set a field to a particular value for all the objects in | ||||
| a ``QuerySet``. You can do this with the ``update()`` method. For example:: | ||||
|  | ||||
| @@ -858,8 +852,6 @@ Just loop over them and call ``save()``:: | ||||
|     for item in my_queryset: | ||||
|         item.save() | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Calls to update can also use :ref:`F() objects <query-expressions>` to update | ||||
| one field based on the value of another field in the model. This is especially | ||||
| useful for incrementing counters based upon their current value. For example, to | ||||
|   | ||||
| @@ -338,8 +338,6 @@ In this example, ``a.save()`` will not be undone in the case where | ||||
| Database-level autocommit | ||||
| ------------------------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| With PostgreSQL 8.2 or later, there is an advanced option to run PostgreSQL | ||||
| with :doc:`database-level autocommit </ref/databases>`. If you use this option, | ||||
| there is no constantly open transaction, so it is always possible to continue | ||||
|   | ||||
| @@ -201,8 +201,6 @@ from the request's POST data, sends that to admin@example.com and redirects to | ||||
| The EmailMessage class | ||||
| ====================== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Django's :meth:`~django.core.mail.send_mail()` and | ||||
| :meth:`~django.core.mail.send_mass_mail()` functions are actually thin | ||||
| wrappers that make use of the :class:`~django.core.mail.EmailMessage` class. | ||||
|   | ||||
| @@ -2,8 +2,6 @@ | ||||
| Managing files | ||||
| ============== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| This document describes Django's file access APIs. | ||||
|  | ||||
| By default, Django stores files locally, using the :setting:`MEDIA_ROOT` and | ||||
|   | ||||
| @@ -176,8 +176,6 @@ itself. When rendering a formset in a template, you can include all | ||||
| the management data by rendering ``{{ my_formset.management_form }}`` | ||||
| (substituting the name of your formset as appropriate). | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| ``total_form_count`` and ``initial_form_count`` | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
|   | ||||
| @@ -114,9 +114,6 @@ There are three code paths here: | ||||
|     3. If the form has been submitted but is invalid, the bound form instance is | ||||
|        passed on to the template. | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|     The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases. | ||||
|  | ||||
| The distinction between **bound** and **unbound** forms is important. An unbound | ||||
| form does not have any data associated with it; when rendered to the user, it | ||||
| will be empty or will contain default values. A bound form does have submitted | ||||
| @@ -345,10 +342,6 @@ error in a hidden field is a sign of form tampering, since normal form | ||||
| interaction won't alter them. However, you could easily insert some error | ||||
| displays for those form errors, as well. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|     The ``hidden_fields`` and ``visible_fields`` methods are new in Django | ||||
|     1.1. | ||||
|  | ||||
| Reusable form templates | ||||
| ----------------------- | ||||
|  | ||||
|   | ||||
| @@ -111,11 +111,6 @@ the full list of conversions: | ||||
|                                      ``widget=forms.Textarea`` | ||||
|     ===============================  ======================================== | ||||
|  | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|     The ``FloatField`` form field and ``DecimalField`` model and form fields | ||||
|     are new in Django 1.0. | ||||
|  | ||||
| .. versionadded:: 1.2 | ||||
|     The ``BigIntegerField`` is new in Django 1.2. | ||||
|  | ||||
| @@ -311,12 +306,8 @@ model fields: | ||||
|  | ||||
| 2. Use the ``fields`` attribute of the ``ModelForm``'s inner ``Meta`` | ||||
|    class.  This attribute, if given, should be a list of field names | ||||
|    to include in the form. | ||||
|  | ||||
|    .. versionchanged:: 1.1 | ||||
|  | ||||
|    The form will render the fields in the same order they are specified in the | ||||
|    ``fields`` attribute. | ||||
|    to include in the form. The order in which the fields names are specified | ||||
|    in that list is respected when the form renders them. | ||||
|  | ||||
| 3. Use the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta`` | ||||
|    class.  This attribute, if given, should be a list of field names | ||||
| @@ -456,8 +447,6 @@ parameter when declaring the form field:: | ||||
| Changing the order of fields | ||||
| ---------------------------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| By default, a ``ModelForm`` will render fields in the same order that they are | ||||
| defined on the model, with ``ManyToManyField`` instances appearing last. If | ||||
| you want to change the order in which fields are rendered, you can use the | ||||
|   | ||||
| @@ -4,8 +4,6 @@ File Uploads | ||||
|  | ||||
| .. currentmodule:: django.core.files | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| When Django handles a file upload, the file data ends up placed in | ||||
| :attr:`request.FILES <django.http.HttpRequest.FILES>` (for more on the | ||||
| ``request`` object see the documentation for :doc:`request and response objects | ||||
|   | ||||
| @@ -29,8 +29,6 @@ from your ``INSTALLED_APPS``. It'll save you a small bit of overhead. | ||||
| Configuring the session engine | ||||
| ============================== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| By default, Django stores sessions in your database (using the model | ||||
| ``django.contrib.sessions.models.Session``). Though this is convenient, in | ||||
| some setups it's faster to store session data elsewhere, so Django can be | ||||
| @@ -50,9 +48,6 @@ Using cached sessions | ||||
|  | ||||
| For better performance, you may want to use a cache-based session backend. | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|    Django 1.0 did not include the ``cached_db`` session backend. | ||||
|  | ||||
| To store session data using Django's cache system, you'll first need to make | ||||
| sure you've configured your cache; see the :doc:`cache documentation | ||||
| </topics/cache>` for details. | ||||
| @@ -138,15 +133,10 @@ A session object has the following standard dictionary methods: | ||||
|  | ||||
|     * ``clear()`` | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    ``setdefault()`` and ``clear()`` are new in this version. | ||||
|  | ||||
| It also has these methods: | ||||
|  | ||||
|     * ``flush()`` | ||||
|  | ||||
|       .. versionadded:: 1.0 | ||||
|  | ||||
|       Delete the current session data from the session and regenerate the | ||||
|       session key value that is sent back to the user in the cookie. This is | ||||
|       used if you want to ensure that the previous session data can't be | ||||
| @@ -173,8 +163,6 @@ It also has these methods: | ||||
|  | ||||
|     * ``set_expiry(value)`` | ||||
|  | ||||
|       .. versionadded:: 1.0 | ||||
|  | ||||
|       Sets the expiration time for the session. You can pass a number of | ||||
|       different values: | ||||
|  | ||||
| @@ -198,24 +186,18 @@ It also has these methods: | ||||
|  | ||||
|     * ``get_expiry_age()`` | ||||
|  | ||||
|       .. versionadded:: 1.0 | ||||
|  | ||||
|       Returns the number of seconds until this session expires. For sessions | ||||
|       with no custom expiration (or those set to expire at browser close), this | ||||
|       will equal ``settings.SESSION_COOKIE_AGE``. | ||||
|  | ||||
|     * ``get_expiry_date()`` | ||||
|  | ||||
|       .. versionadded:: 1.0 | ||||
|  | ||||
|       Returns the date this session will expire. For sessions with no custom | ||||
|       expiration (or those set to expire at browser close), this will equal the | ||||
|       date ``settings.SESSION_COOKIE_AGE`` seconds from now. | ||||
|  | ||||
|     * ``get_expire_at_browser_close()`` | ||||
|  | ||||
|       .. versionadded:: 1.0 | ||||
|  | ||||
|       Returns either ``True`` or ``False``, depending on whether the user's | ||||
|       session cookie will expire when the user's Web browser is closed. | ||||
|  | ||||
| @@ -302,8 +284,6 @@ Here's a typical usage example:: | ||||
| Using sessions out of views | ||||
| =========================== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| An API is available to manipulate session data outside of a view:: | ||||
|  | ||||
|     >>> from django.contrib.sessions.backends.db import SessionStore | ||||
| @@ -393,8 +373,6 @@ browser-length cookies -- cookies that expire as soon as the user closes his or | ||||
| her browser. Use this if you want people to have to log in every time they open | ||||
| a browser. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| This setting is a global default and can be overwritten at a per-session level | ||||
| by explicitly calling ``request.session.set_expiry()`` as described above in | ||||
| `using sessions in views`_. | ||||
| @@ -424,11 +402,6 @@ A few :doc:`Django settings </ref/settings>` give you control over session behav | ||||
| SESSION_ENGINE | ||||
| -------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. versionchanged:: 1.1 | ||||
|    The ``cached_db`` backend was added | ||||
|  | ||||
| Default: ``django.contrib.sessions.backends.db`` | ||||
|  | ||||
| Controls where Django stores session data. Valid values are: | ||||
| @@ -443,8 +416,6 @@ See `configuring the session engine`_ for more details. | ||||
| SESSION_FILE_PATH | ||||
| ----------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``/tmp/`` | ||||
|  | ||||
| If you're using file-based session storage, this sets the directory in | ||||
| @@ -493,8 +464,6 @@ The name of the cookie to use for sessions. This can be whatever you want. | ||||
| SESSION_COOKIE_PATH | ||||
| ------------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Default: ``'/'`` | ||||
|  | ||||
| The path set on the session cookie. This should either match the URL path of | ||||
|   | ||||
| @@ -152,8 +152,6 @@ This example is equivalent to:: | ||||
|  | ||||
| .. function:: redirect(to[, permanent=False], *args, **kwargs) | ||||
|  | ||||
|    .. versionadded:: 1.1 | ||||
|  | ||||
|    Returns an :class:`~django.http.HttpResponseRedirect` to the appropriate URL | ||||
|    for the arguments passed. | ||||
|  | ||||
|   | ||||
| @@ -225,8 +225,6 @@ The remaining arguments should be tuples in this format:: | ||||
| url | ||||
| --- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. function:: url(regex, view, kwargs=None, name=None, prefix='') | ||||
|  | ||||
| You can use the ``url()`` function, instead of a tuple, as an argument to | ||||
| @@ -285,8 +283,6 @@ include | ||||
| A function that takes a full Python import path to another URLconf module that | ||||
| should be "included" in this place. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| :func:`include` also accepts as an argument an iterable that returns URL | ||||
| patterns. | ||||
|  | ||||
| @@ -417,8 +413,6 @@ Django encounters ``include()``, it chops off whatever part of the URL matched | ||||
| up to that point and sends the remaining string to the included URLconf for | ||||
| further processing. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Another possibility is to include additional URL patterns not by specifying the | ||||
| URLconf Python module defining them as the `include`_ argument but by using | ||||
| directly the pattern list as returned by `patterns`_ instead. For example:: | ||||
| @@ -637,8 +631,6 @@ the view prefix (as explained in "The view prefix" above) will have no effect. | ||||
| Naming URL patterns | ||||
| =================== | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| It's fairly common to use the same view function in multiple URL patterns in | ||||
| your URLconf. For example, these two URL patterns both point to the ``archive`` | ||||
| view:: | ||||
| @@ -697,8 +689,6 @@ not restricted to valid Python names. | ||||
| URL namespaces | ||||
| -------------- | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| Namespaced URLs are specified using the ``:`` operator. For example, the main | ||||
| index page of the admin application is referenced using ``admin:index``. This | ||||
| indicates a namespace of ``admin``, and a named URL of ``index``. | ||||
| @@ -804,8 +794,6 @@ vertical bar (``"|"``) character. You can quite happily use such patterns for | ||||
| matching against incoming URLs and sending them off to views, but you cannot | ||||
| reverse such patterns. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| The ``current_app`` argument allows you to provide a hint to the resolver | ||||
| indicating the application to which the currently executing view belongs. | ||||
| This ``current_app`` argument is used as a hint to resolve application | ||||
| @@ -935,8 +923,6 @@ get_script_prefix() | ||||
|  | ||||
| .. function:: get_script_prefix() | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| Normally, you should always use :func:`~django.core.urlresolvers.reverse` or | ||||
| :func:`~django.db.models.permalink` to define URLs within your application. | ||||
| However, if your application constructs part of the URL hierarchy itself, you | ||||
|   | ||||
| @@ -81,12 +81,8 @@ following this algorithm: | ||||
|  | ||||
|     * Failing that, it looks for a cookie. | ||||
|  | ||||
|       .. versionchanged:: 1.0 | ||||
|  | ||||
|       In Django version 0.96 and before, the cookie's name is hard-coded to | ||||
|       ``django_language``. In Django 1,0, The cookie name is set by the | ||||
|       ``LANGUAGE_COOKIE_NAME`` setting. (The default name is | ||||
|       ``django_language``.) | ||||
|       The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME`` | ||||
|       setting. (The default name is ``django_language``.) | ||||
|  | ||||
|     * Failing that, it looks at the ``Accept-Language`` HTTP header. This | ||||
|       header is sent by your browser and tells the server which language(s) you | ||||
|   | ||||
| @@ -5,9 +5,6 @@ Pagination | ||||
| .. module:: django.core.paginator | ||||
|    :synopsis: Classes to help you easily manage paginated data. | ||||
|  | ||||
| .. versionchanged:: 1.0 | ||||
|    Pagination facilities have been almost fully reworked. | ||||
|  | ||||
| Django provides a few classes that help you manage paginated data -- that is, | ||||
| data that's split across several pages, with "Previous/Next" links. These | ||||
| classes live in :file:`django/core/paginator.py`. | ||||
|   | ||||
| @@ -403,8 +403,6 @@ wouldn't know which one of the blocks' content to use. | ||||
| Automatic HTML escaping | ||||
| ======================= | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| When generating HTML from templates, there's always a risk that a variable will | ||||
| include characters that affect the resulting HTML. For example, consider this | ||||
| template fragment:: | ||||
|   | ||||
| @@ -288,9 +288,6 @@ with this command:: | ||||
|  | ||||
| Note that we used ``animals``, not ``myproject.animals``. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|    You can now choose which test to run. | ||||
|  | ||||
| You can be even *more* specific by naming an individual test case. To | ||||
| run a single test case in an application (for example, the | ||||
| ``AnimalTestCase`` described in the "Writing unit tests" section), add | ||||
| @@ -393,8 +390,6 @@ database is created by the user specified by ``USER``, so you'll need | ||||
| to make sure that the given user account has sufficient privileges to | ||||
| create a new database on the system. | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| For fine-grained control over the character encoding of your test | ||||
| database, use the :setting:`TEST_CHARSET` option. If you're using | ||||
| MySQL, you can also use the :setting:`TEST_COLLATION` option to | ||||
| @@ -718,8 +713,6 @@ arguments at time of construction: | ||||
|         details	view, which is a good way to test code paths that use the | ||||
|         :meth:`django.http.HttpRequest.is_ajax()` method. | ||||
|  | ||||
|         .. versionadded:: 1.1 | ||||
|  | ||||
|         If you already have the GET arguments in URL-encoded form, you can | ||||
|         use that encoding instead of using the data argument. For example, | ||||
|         the previous GET request could also be posed as:: | ||||
| @@ -802,8 +795,6 @@ arguments at time of construction: | ||||
|  | ||||
|         The ``extra`` argument acts the same as for :meth:`Client.get`. | ||||
|  | ||||
|         .. versionchanged:: 1.1 | ||||
|  | ||||
|         If the URL you request with a POST contains encoded parameters, these | ||||
|         parameters will be made available in the request.GET data. For example, | ||||
|         if you were to make the request:: | ||||
| @@ -820,8 +811,6 @@ arguments at time of construction: | ||||
|  | ||||
|     .. method:: Client.head(path, data={}, follow=False, **extra) | ||||
|  | ||||
|         .. versionadded:: 1.1 | ||||
|  | ||||
|         Makes a HEAD request on the provided ``path`` and returns a ``Response`` | ||||
|         object. Useful for testing RESTful interfaces. Acts just like | ||||
|         :meth:`Client.get` except it does not return a message body. | ||||
| @@ -832,8 +821,6 @@ arguments at time of construction: | ||||
|  | ||||
|     .. method:: Client.options(path, data={}, follow=False, **extra) | ||||
|  | ||||
|         .. versionadded:: 1.1 | ||||
|  | ||||
|         Makes an OPTIONS request on the provided ``path`` and returns a | ||||
|         ``Response`` object. Useful for testing RESTful interfaces. | ||||
|  | ||||
| @@ -845,8 +832,6 @@ arguments at time of construction: | ||||
|  | ||||
|     .. method:: Client.put(path, data={}, content_type=MULTIPART_CONTENT, follow=False, **extra) | ||||
|  | ||||
|         .. versionadded:: 1.1 | ||||
|  | ||||
|         Makes a PUT request on the provided ``path`` and returns a | ||||
|         ``Response`` object. Useful for testing RESTful interfaces. Acts just | ||||
|         like :meth:`Client.post` except with the PUT request method. | ||||
| @@ -857,8 +842,6 @@ arguments at time of construction: | ||||
|  | ||||
|     .. method:: Client.delete(path, follow=False, **extra) | ||||
|  | ||||
|         .. versionadded:: 1.1 | ||||
|  | ||||
|         Makes an DELETE request on the provided ``path`` and returns a | ||||
|         ``Response`` object. Useful for testing RESTful interfaces. | ||||
|  | ||||
| @@ -870,8 +853,6 @@ arguments at time of construction: | ||||
|  | ||||
|     .. method:: Client.login(**credentials) | ||||
|  | ||||
|         .. versionadded:: 1.0 | ||||
|  | ||||
|         If your site uses Django's :doc:`authentication system</topics/auth>` | ||||
|         and you deal with logging in users, you can use the test client's | ||||
|         ``login()`` method to simulate the effect of a user logging into the | ||||
| @@ -916,8 +897,6 @@ arguments at time of construction: | ||||
|  | ||||
|     .. method:: Client.logout() | ||||
|  | ||||
|         .. versionadded:: 1.0 | ||||
|  | ||||
|         If your site uses Django's :doc:`authentication system</topics/auth>`, | ||||
|         the ``logout()`` method can be used to simulate the effect of a user | ||||
|         logging out of your site. | ||||
| @@ -956,8 +935,6 @@ Specifically, a ``Response`` object has the following attributes: | ||||
|         If the rendered page used multiple templates, then ``context`` will be a | ||||
|         list of ``Context`` objects, in the order in which they were rendered. | ||||
|  | ||||
|         .. versionadded:: 1.1 | ||||
|  | ||||
|         Regardless of the number of templates used during rendering, you can | ||||
|         retrieve context values using the ``[]`` operator. For example, the | ||||
|         context variable ``name`` could be retrieved using:: | ||||
| @@ -1127,8 +1104,6 @@ just change the base class of your test from ``unittest.TestCase`` to | ||||
| will continue to be available, but it will be augmented with some useful | ||||
| additions. | ||||
|  | ||||
| .. versionadded:: 1.1 | ||||
|  | ||||
| .. class:: TransactionTestCase() | ||||
|  | ||||
| Django ``TestCase`` classes make use of database transaction facilities, if | ||||
| @@ -1176,8 +1151,6 @@ by truncating tables and reloading initial data. | ||||
| Default test client | ||||
| ~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. attribute:: TestCase.client | ||||
|  | ||||
| Every test case in a ``django.test.TestCase`` instance has access to an | ||||
| @@ -1305,8 +1278,6 @@ or by the order of test execution. | ||||
| URLconf configuration | ||||
| ~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. attribute:: TestCase.urls | ||||
|  | ||||
| If your application provides views, you may want to include tests that use the | ||||
| @@ -1374,8 +1345,6 @@ This test case will flush *all* the test databases before running | ||||
| Emptying the test outbox | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If you use Django's custom ``TestCase`` class, the test runner will clear the | ||||
| contents of the test e-mail outbox at the start of each test case. | ||||
|  | ||||
| @@ -1384,8 +1353,6 @@ For more detail on e-mail services during tests, see `E-mail services`_. | ||||
| Assertions | ||||
| ~~~~~~~~~~ | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| .. versionchanged:: 1.2 | ||||
|     Addded ``msg_prefix`` argument. | ||||
|  | ||||
| @@ -1444,8 +1411,6 @@ cause of an failure in your test suite. | ||||
|     redirected to ``expected_url`` (including any GET data), and the final | ||||
|     page was received with ``target_status_code``. | ||||
|  | ||||
|     .. versionadded:: 1.1 | ||||
|  | ||||
|     If your request used the ``follow`` argument, the ``expected_url`` and | ||||
|     ``target_status_code`` will be the url and status code for the final | ||||
|     point of the redirect chain. | ||||
| @@ -1496,8 +1461,6 @@ cause of an failure in your test suite. | ||||
| E-mail services | ||||
| --------------- | ||||
|  | ||||
| .. versionadded:: 1.0 | ||||
|  | ||||
| If any of your Django views send e-mail using :doc:`Django's e-mail | ||||
| functionality </topics/email>`, you probably don't want to send e-mail each time | ||||
| you run a test using that view. For this reason, Django's test runner | ||||
| @@ -1801,9 +1764,6 @@ also provides some utilities that can be useful during testing. | ||||
|     :setting:`NAME` in :setting:`DATABASES` to match the name of the test | ||||
|     database. | ||||
|  | ||||
|     .. versionchanged:: 1.0 | ||||
|        ``create_test_db()`` now returns the name of the test database. | ||||
|  | ||||
| .. function:: destroy_test_db(old_database_name, verbosity=1) | ||||
|  | ||||
|     Destroys the database whose name is in stored in :setting:`NAME` in the | ||||
|   | ||||
		Reference in New Issue
	
	Block a user