diff --git a/docs/ref/contrib/gis/gdal.txt b/docs/ref/contrib/gis/gdal.txt index c4b29bead7..161efa39de 100644 --- a/docs/ref/contrib/gis/gdal.txt +++ b/docs/ref/contrib/gis/gdal.txt @@ -13,7 +13,7 @@ of GDAL is the `OGR`__ Simple Features Library, which specializes in reading and writing vector geographic data in a variety of standard formats. -GeoDjango provides a high-level Python interface for some of the +GeoDjango provides a high-level Python interface for some of the capabilities of OGR, including the reading and coordinate transformation of vector spatial data. @@ -22,7 +22,7 @@ of vector spatial data. Although the module is named ``gdal``, GeoDjango only supports some of the capabilities of OGR. Thus, none of GDAL's features with respect to raster (image) data are supported at this time. - + __ http://www.gdal.org/ __ http://www.gdal.org/ogr/ @@ -68,13 +68,13 @@ each feature in that layer. also supports a variety of more complex data sources, including databases, that may be accessed by passing a special name string instead of a path. For more information, see the `OGR Vector Formats`__ - documentation. The :attr:`name` property of a ``DataSource`` + documentation. The :attr:`name` property of a ``DataSource`` instance gives the OGR name of the underlying data source that it is using. - Once you've created your ``DataSource``, you can find out how many - layers of data it contains by accessing the :attr:`layer_count` property, - or (equivalently) by using the ``len()`` function. For information on + Once you've created your ``DataSource``, you can find out how many + layers of data it contains by accessing the :attr:`layer_count` property, + or (equivalently) by using the ``len()`` function. For information on accessing the layers of data themselves, see the next section:: >>> from django.contrib.gis.gdal import DataSource @@ -105,7 +105,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html Python container of ``Layer`` objects. For example, you can access a specific layer by its index (e.g. ``ds[0]`` to access the first layer), or you can iterate over all the layers in the container in a - ``for`` loop. The ``Layer`` itself acts as a container for geometric + ``for`` loop. The ``Layer`` itself acts as a container for geometric features. Typically, all the features in a given layer have the same geometry type. @@ -120,7 +120,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html The example output is from the cities data source, loaded above, which evidently contains one layer, called ``"cities"``, which contains three - point features. For simplicity, the examples below assume that you've + point features. For simplicity, the examples below assume that you've stored that layer in the variable ``layer``:: >>> layer = ds[0] @@ -169,7 +169,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html >>> [ft.__name__ for ft in layer.field_types] ['OFTString', 'OFTReal', 'OFTReal', 'OFTDate'] - + .. attribute:: field_widths Returns a list of the maximum field widths for each of the fields in @@ -181,7 +181,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html .. attribute:: field_precisions Returns a list of the numeric precisions for each of the fields in - this layer. This is meaningless (and set to zero) for non-numeric + this layer. This is meaningless (and set to zero) for non-numeric fields:: >>> layer.field_precisions @@ -189,7 +189,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html .. attribute:: extent - Returns the spatial extent of this layer, as an :class:`Envelope` + Returns the spatial extent of this layer, as an :class:`Envelope` object:: >>> layer.extent.tuple @@ -214,7 +214,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html Property that may be used to retrieve or set a spatial filter for this layer. A spatial filter can only be set with an :class:`OGRGeometry` - instance, a 4-tuple extent, or ``None``. When set with something + instance, a 4-tuple extent, or ``None``. When set with something other than ``None``, only features that intersect the filter will be returned when iterating over the layer:: @@ -258,9 +258,9 @@ __ http://www.gdal.org/ogr/ogr_formats.html given capability (a string). Examples of valid capability strings include: ``'RandomRead'``, ``'SequentialWrite'``, ``'RandomWrite'``, ``'FastSpatialFilter'``, ``'FastFeatureCount'``, ``'FastGetExtent'``, - ``'CreateField'``, ``'Transactions'``, ``'DeleteFeature'``, and + ``'CreateField'``, ``'Transactions'``, ``'DeleteFeature'``, and ``'FastSetNextByIndex'``. - + ``Feature`` ----------- @@ -295,14 +295,14 @@ __ http://www.gdal.org/ogr/ogr_formats.html Returns the type of geometry for this feature, as an :class:`OGRGeomType` object. This will be the same for all features in a given layer, and - is equivalent to the :attr:`Layer.geom_type` property of the - :class:`Layer`` object the feature came from. + is equivalent to the :attr:`Layer.geom_type` property of the + :class:`Layer` object the feature came from. .. attribute:: num_fields Returns the number of fields of data associated with the feature. This will be the same for all features in a given layer, and is - equivalent to the :attr:`Layer.num_fields` property of the + equivalent to the :attr:`Layer.num_fields` property of the :class:`Layer` object the feature came from. .. attribute:: fields @@ -350,7 +350,7 @@ __ http://www.gdal.org/ogr/ogr_formats.html .. attribute:: type Returns the OGR type of this field, as an integer. The - ``FIELD_CLASSES`` dictionary maps these values onto + ``FIELD_CLASSES`` dictionary maps these values onto subclasses of ``Field``:: >>> city['Density'].type @@ -365,8 +365,8 @@ __ http://www.gdal.org/ogr/ogr_formats.html .. attribute:: value - Returns the value of this field. The ``Field`` class itself - returns the value as a string, but each subclass returns the + Returns the value of this field. The ``Field`` class itself + returns the value as a string, but each subclass returns the value in the most appropriate form:: >>> city['Population'].value @@ -433,10 +433,10 @@ OGR Geometries ``OGRGeometry`` --------------- -:class:`OGRGeometry` objects share similar functionality with +:class:`OGRGeometry` objects share similar functionality with :class:`~django.contrib.gis.geos.GEOSGeometry` objects, and are thin -wrappers around OGR's internal geometry representation. Thus, -they allow for more efficient access to data when using :class:`DataSource`. +wrappers around OGR's internal geometry representation. Thus, +they allow for more efficient access to data when using :class:`DataSource`. Unlike its GEOS counterpart, :class:`OGRGeometry` supports spatial reference systems and coordinate transformation:: @@ -446,10 +446,10 @@ systems and coordinate transformation:: .. class:: OGRGeometry(geom_input[, srs=None]) This object is a wrapper for the `OGR Geometry`__ class. - These objects are instantiated directly from the given ``geom_input`` + These objects are instantiated directly from the given ``geom_input`` parameter, which may be a string containing WKT, HEX, GeoJSON, a ``buffer`` containing WKB data, or an :class:`OGRGeomType` object. These objects - are also returned from the :class:`Feature.geom` attribute, when + are also returned from the :class:`Feature.geom` attribute, when reading vector data from :class:`Layer` (which is in turn a part of a :class:`DataSource`). @@ -557,14 +557,14 @@ systems and coordinate transformation:: .. attribute:: srid - Returns or sets the spatial reference identifier corresponding to + Returns or sets the spatial reference identifier corresponding to :class:`SpatialReference` of this geometry. Returns ``None`` if there is no spatial reference information associated with this geometry, or if an SRID cannot be determined. .. attribute:: geos - Returns a :class:`~django.contrib.gis.geos.GEOSGeometry` object + Returns a :class:`~django.contrib.gis.geos.GEOSGeometry` object corresponding to this geometry. .. attribute:: gml @@ -762,9 +762,9 @@ systems and coordinate transformation:: .. attribute:: z - Returns a list of Z coordinates in this line, or ``None`` if the + Returns a list of Z coordinates in this line, or ``None`` if the line does not have Z coordinates:: - + >>> OGRGeometry('LINESTRING (1 2 3,4 5 6)').z [3.0, 6.0] @@ -885,7 +885,7 @@ Coordinate System Objects Spatial reference objects are initialized on the given ``srs_input``, which may be one of the following: - + * OGC Well Known Text (WKT) (a string) * EPSG code (integer or string) * PROJ.4 string @@ -912,7 +912,7 @@ Coordinate System Objects .. method:: __getitem__(target) Returns the value of the given string attribute node, ``None`` if the node - doesn't exist. Can also take a tuple as a parameter, (target, child), + doesn't exist. Can also take a tuple as a parameter, (target, child), where child is the index of the attribute in the WKT. For example:: >>> wkt = 'GEOGCS["WGS 84", DATUM["WGS_1984, ... AUTHORITY["EPSG","4326"]]') @@ -1011,7 +1011,7 @@ Coordinate System Objects .. attribute:: units - Returns a 2-tuple of the units value and the units name, + Returns a 2-tuple of the units value and the units name, and will automatically determines whether to return the linear or angular units. @@ -1073,7 +1073,7 @@ Coordinate System Objects .. class:: CoordTransform(source, target) -Represents a coordinate system transform. It is initialized with two +Represents a coordinate system transform. It is initialized with two :class:`SpatialReference`, representing the source and target coordinate systems, respectively. These objects should be used when performing the same coordinate transformation repeatedly on different geometries:: diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index cd1185585c..a33c985e2c 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -919,7 +919,7 @@ A :class:`CharField` for a URL. The default form widget for this field is a :class:`~django.forms.TextInput`. Like all :class:`CharField` subclasses, :class:`URLField` takes the optional -:attr:`~CharField.max_length`argument. If you don't specify +:attr:`~CharField.max_length` argument. If you don't specify :attr:`~CharField.max_length`, a default of 200 is used. .. versionadded:: 1.5 diff --git a/docs/ref/models/options.txt b/docs/ref/models/options.txt index a577135271..ac20422915 100644 --- a/docs/ref/models/options.txt +++ b/docs/ref/models/options.txt @@ -85,14 +85,14 @@ Django quotes column and table names behind the scenes. The name of an orderable field in the model, typically a :class:`DateField`, :class:`DateTimeField`, or :class:`IntegerField`. This specifies the default - field to use in your model :class:`Manager`'s :class:`~QuerySet.latest` - method. + field to use in your model :class:`Manager`'s + :meth:`~django.db.models.query.QuerySet.latest` method. Example:: get_latest_by = "order_date" - See the docs for :meth:`~django.db.models.query.QuerySet.latest` for more. + See the :meth:`~django.db.models.query.QuerySet.latest` docs for more. ``managed`` ----------- diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index 40fa2d2b2f..a19d022c58 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -1637,7 +1637,7 @@ Finally, realize that ``update()`` does an update at the SQL level and, thus, does not call any ``save()`` methods on your models, nor does it emit the :attr:`~django.db.models.signals.pre_save` or :attr:`~django.db.models.signals.post_save` signals (which are a consequence of -calling :meth:`Model.save() <~django.db.models.Model.save()>`). If you want to +calling :meth:`Model.save() `). If you want to update a bunch of records for a model that has a custom :meth:`~django.db.models.Model.save()` method, loop over them and call :meth:`~django.db.models.Model.save()`, like this:: diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index 5ecc221039..7cb33a038d 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -159,7 +159,7 @@ The cache backend to use. The built-in cache backends are: * ``'django.core.cache.backends.memcached.PyLibMCCache'`` You can use a cache backend that doesn't ship with Django by setting -:setting:`BACKEND ` to a fully-qualified path of a cache +:setting:`BACKEND ` to a fully-qualified path of a cache backend class (i.e. ``mypackage.backends.whatever.WhateverCache``). Writing a whole new cache backend from scratch is left as an exercise to the reader; see the other backends for examples. @@ -830,7 +830,7 @@ DEFAULT_EXCEPTION_REPORTER_FILTER Default: :class:`django.views.debug.SafeExceptionReporterFilter` Default exception reporter filter class to be used if none has been assigned to -the :class:`HttpRequest` instance yet. +the :class:`~django.http.HttpRequest` instance yet. See :ref:`Filtering error reports`. .. setting:: DEFAULT_FILE_STORAGE @@ -1070,6 +1070,8 @@ Note that these paths should use Unix-style forward slashes, even on Windows. See :ref:`initial-data-via-fixtures` and :ref:`topics-testing-fixtures`. +.. setting:: FORCE_SCRIPT_NAME + FORCE_SCRIPT_NAME ------------------ @@ -1498,7 +1500,7 @@ PROFANITIES_LIST Default: ``()`` (Empty tuple) A tuple of profanities, as strings, that will be forbidden in comments when -:setting:`COMMENTS_ALLOW_PROFANITIES` is ``False``. +``COMMENTS_ALLOW_PROFANITIES`` is ``False``. .. setting:: RESTRUCTUREDTEXT_FILTER_SETTINGS diff --git a/docs/releases/1.1-alpha-1.txt b/docs/releases/1.1-alpha-1.txt index c8ac56cf48..b20b4103b8 100644 --- a/docs/releases/1.1-alpha-1.txt +++ b/docs/releases/1.1-alpha-1.txt @@ -32,11 +32,13 @@ Aggregate support It's now possible to run SQL aggregate queries (i.e. ``COUNT()``, ``MAX()``, ``MIN()``, etc.) from within Django's ORM. You can choose to either return the results of the aggregate directly, or else annotate the objects in a -:class:`QuerySet` with the results of the aggregate query. +:class:`~django.db.models.query.QuerySet` with the results of the aggregate +query. -This feature is available as new :meth:`QuerySet.aggregate()`` and -:meth:`QuerySet.annotate()`` methods, and is covered in detail in :doc:`the ORM -aggregation documentation ` +This feature is available as new +:meth:`~django.db.models.query.QuerySet.aggregate` and +:meth:`~django.db.models.query.QuerySet.annotate` methods, and is covered in +detail in :doc:`the ORM aggregation documentation `. Query expressions ~~~~~~~~~~~~~~~~~ diff --git a/docs/releases/1.1.txt b/docs/releases/1.1.txt index 84af7fc1d9..595f59a52a 100644 --- a/docs/releases/1.1.txt +++ b/docs/releases/1.1.txt @@ -198,11 +198,13 @@ Aggregate support It's now possible to run SQL aggregate queries (i.e. ``COUNT()``, ``MAX()``, ``MIN()``, etc.) from within Django's ORM. You can choose to either return the results of the aggregate directly, or else annotate the objects in a -:class:`QuerySet` with the results of the aggregate query. +:class:`~django.db.models.query.QuerySet` with the results of the aggregate +query. -This feature is available as new :meth:`QuerySet.aggregate()`` and -:meth:`QuerySet.annotate()`` methods, and is covered in detail in :doc:`the ORM -aggregation documentation `. +This feature is available as new +:meth:`~django.db.models.query.QuerySet.aggregate` and +:meth:`~django.db.models.query.QuerySet.annotate` methods, and is covered in +detail in :doc:`the ORM aggregation documentation `. Query expressions ~~~~~~~~~~~~~~~~~ diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt index 2f5124e52b..dac48a4363 100644 --- a/docs/releases/1.3-alpha-1.txt +++ b/docs/releases/1.3-alpha-1.txt @@ -61,15 +61,14 @@ Django 1.3 ships with a new contrib app ``'django.contrib.staticfiles'`` to help developers handle the static media files (images, CSS, Javascript, etc.) that are needed to render a complete web page. -In previous versions of Django, it was common to place static assets in -:setting:`MEDIA_ROOT` along with user-uploaded files, and serve them both at -:setting:`MEDIA_URL`. Part of the purpose of introducing the ``staticfiles`` -app is to make it easier to keep static files separate from user-uploaded -files. For this reason, you will probably want to make your -:setting:`MEDIA_ROOT` and :setting:`MEDIA_URL` different from your -:setting:`STATICFILES_ROOT` and :setting:`STATICFILES_URL`. You will need to -arrange for serving of files in :setting:`MEDIA_ROOT` yourself; -``staticfiles`` does not deal with user-uploaded media at all. +In previous versions of Django, it was common to place static assets +in :setting:`MEDIA_ROOT` along with user-uploaded files, and serve +them both at :setting:`MEDIA_URL`. Part of the purpose of introducing +the ``staticfiles`` app is to make it easier to keep static files +separate from user-uploaded files. Static assets should now go in +``static/`` subdirectories of your apps or in other static assets +directories listed in :setting:`STATICFILES_DIRS`, and will be served +at :setting:`STATIC_URL`. See the :doc:`reference documentation of the app ` for more details or learn how to :doc:`manage static files diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index 01532cc04c..9ff42accc5 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -37,8 +37,8 @@ Other notable new features in Django 1.4 include: the ability to `bulk insert <#model-objects-bulk-create-in-the-orm>`_ large datasets for improved performance, and `QuerySet.prefetch_related`_, a method to batch-load related objects - in areas where :meth:`~django.db.models.QuerySet.select_related` doesn't - work. + in areas where :meth:`~django.db.models.query.QuerySet.select_related` + doesn't work. * Some nice security additions, including `improved password hashing`_ (featuring PBKDF2_ and bcrypt_ support), new `tools for cryptographic