mirror of
				https://github.com/django/django.git
				synced 2025-10-31 09:41:08 +00:00 
			
		
		
		
	gis: Merged revisions 4799-4809 via svnmerge.
Last revision prior to 0.96 release. git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@4853 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
		| @@ -1 +1 @@ | ||||
| VERSION = (0, 96, 'pre') | ||||
| VERSION = (0, 96, None) | ||||
|   | ||||
| @@ -51,8 +51,6 @@ See the `csrf documentation`_. | ||||
| formtools | ||||
| ========= | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| A set of high-level abstractions for Django forms (django.newforms). | ||||
|  | ||||
| django.contrib.formtools.preview | ||||
| @@ -142,8 +140,6 @@ See the `flatpages documentation`_. | ||||
| localflavor | ||||
| =========== | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| A collection of various Django snippets that are useful only for a particular | ||||
| country or culture. For example, ``django.contrib.localflavor.usa.forms`` | ||||
| contains a ``USZipCodeField`` that you can use to validate U.S. zip codes. | ||||
|   | ||||
| @@ -100,8 +100,6 @@ if you're ever curious to see the full list of defaults. | ||||
| dumpdata [appname appname ...] | ||||
| ------------------------------ | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Output to standard output all data in the database associated with the named  | ||||
| application(s). | ||||
|  | ||||
| @@ -117,8 +115,6 @@ The output of ``dumpdata`` can be used as input for ``loaddata``. | ||||
| flush | ||||
| ----- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Return the database to the state it was in immediately after syncdb was  | ||||
| executed. This means that all data will be removed from the database, any  | ||||
| post-synchronization handlers will be re-executed, and the ``initial_data`` | ||||
| @@ -165,18 +161,9 @@ needed. | ||||
| ``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection | ||||
| only works in PostgreSQL and with certain types of MySQL tables. | ||||
|  | ||||
| install [appname appname ...] | ||||
| ----------------------------- | ||||
|  | ||||
| **Removed in Django development version** | ||||
|  | ||||
| Executes the equivalent of ``sqlall`` for the given appnames. | ||||
|  | ||||
| loaddata [fixture fixture ...] | ||||
| ------------------------------ | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Searches for and loads the contents of the named fixture into the database. | ||||
|  | ||||
| A *Fixture* is a collection of files that contain the serialized contents of | ||||
| @@ -350,8 +337,6 @@ Prints the DROP TABLE SQL statements for the given appnames. | ||||
| sqlcustom [appname appname ...] | ||||
| ------------------------------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Prints the custom SQL statements for the given appnames. | ||||
|  | ||||
| For each model in each specified app, this command looks for the file | ||||
| @@ -373,13 +358,6 @@ sqlindexes [appname appname ...] | ||||
|  | ||||
| Prints the CREATE INDEX SQL statements for the given appnames. | ||||
|  | ||||
| sqlinitialdata [appname appname ...] | ||||
| -------------------------------------------- | ||||
|  | ||||
| **Removed in Django development version** | ||||
|  | ||||
| This method has been renamed ``sqlcustom`` in the development version of Django.  | ||||
|  | ||||
| sqlreset [appname appname ...] | ||||
| -------------------------------------- | ||||
|  | ||||
| @@ -426,8 +404,6 @@ fixture data files. | ||||
| test | ||||
| ---- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Discover and run tests for all installed models.  See `Testing Django applications`_ for more information. | ||||
|  | ||||
| .. _testing django applications: ../testing/ | ||||
| @@ -475,8 +451,6 @@ setting the Python path for you. | ||||
| --format | ||||
| -------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Example usage:: | ||||
|  | ||||
|     django-admin.py dumpdata --format=xml | ||||
| @@ -493,8 +467,6 @@ options. | ||||
| --indent | ||||
| -------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Example usage:: | ||||
|  | ||||
|     django-admin.py dumpdata --indent=4 | ||||
| @@ -506,8 +478,6 @@ Pretty-printing will only be enabled if the indent option is provided. | ||||
| --noinput | ||||
| --------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Inform django-admin that the user should NOT be prompted for any input. Useful | ||||
| if the django-admin script will be executed as an unattended, automated | ||||
| script. | ||||
| @@ -530,8 +500,6 @@ Example output:: | ||||
| --verbosity | ||||
| ----------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Example usage:: | ||||
|  | ||||
|     django-admin.py syncdb --verbosity=2 | ||||
| @@ -543,8 +511,6 @@ and `2` is verbose output. | ||||
| --adminmedia | ||||
| ------------ | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Example usage:: | ||||
|     django-admin.py manage.py --adminmedia=/tmp/new-admin-style/ | ||||
|  | ||||
|   | ||||
| @@ -97,8 +97,7 @@ which is a dictionary of the parameters captured in the URL. | ||||
|     * ``extra_context``: A dictionary of values to add to the template | ||||
|       context. By default, this is an empty dictionary. If a value in the | ||||
|       dictionary is callable, the generic view will call it | ||||
|       just before rendering the template. (**This is new in the | ||||
|       Django development version.**) | ||||
|       just before rendering the template. | ||||
|  | ||||
| **Example:** | ||||
|  | ||||
| @@ -752,10 +751,10 @@ If the results are paginated, the context will contain these extra variables: | ||||
|  | ||||
|     * ``previous``: The previous page number, as an integer. This is 1-based. | ||||
|  | ||||
|     * `last_on_page`: **New in Django development version** The number of the | ||||
|     * `last_on_page`: The number of the | ||||
|       last result on the current page. This is 1-based. | ||||
|  | ||||
|     * `first_on_page`: **New in Django development version** The number of the | ||||
|     * `first_on_page`: The number of the | ||||
|       first result on the current page. This is 1-based. | ||||
|  | ||||
|     * ``pages``: The total number of pages, as an integer. | ||||
|   | ||||
| @@ -104,8 +104,6 @@ Also removes the content from any response to a HEAD request and sets the | ||||
| django.middleware.http.SetRemoteAddrFromForwardedFor | ||||
| ---------------------------------------------------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Sets ``request.META['REMOTE_ADDR']`` based on | ||||
| ``request.META['HTTP_X_FORWARDED_FOR']``, if the latter is set. This is useful | ||||
| if you're sitting behind a reverse proxy that causes each request's | ||||
|   | ||||
| @@ -362,9 +362,8 @@ Like a ``PositiveIntegerField``, but only allows values under a certain | ||||
| containing only letters, numbers, underscores or hyphens. They're generally | ||||
| used in URLs. | ||||
|  | ||||
| In the Django development version, you can specify ``maxlength``. If | ||||
| ``maxlength`` is not specified, Django will use a default length of 50. In | ||||
| previous Django versions, there's no way to override the length of 50. | ||||
| Like a CharField, you can specify ``maxlength``. If ``maxlength`` is | ||||
| not specified, Django will use a default length of 50. | ||||
|  | ||||
| Implies ``db_index=True``. | ||||
|  | ||||
| @@ -1457,8 +1456,8 @@ user searches for ``john lennon``, Django will do the equivalent of this SQL | ||||
|     WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%') | ||||
|     AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%') | ||||
|  | ||||
| **New in Django development version:** For faster and/or more restrictive | ||||
| searches, prefix the field name with an operator: | ||||
| For faster and/or more restrictive searches, prefix the field name | ||||
| with an operator: | ||||
|  | ||||
| ``^`` | ||||
|     Matches the beginning of the field. For example, if ``search_fields`` is | ||||
| @@ -1754,8 +1753,6 @@ But this template code is good:: | ||||
| The ``permalink`` decorator | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| **New in Django development version.** | ||||
|  | ||||
| The problem with the way we wrote ``get_absolute_url()`` above is that it | ||||
| slightly violates the DRY principle: the URL for this object is defined both | ||||
| in the URLConf file and in the model. | ||||
|   | ||||
| @@ -9,9 +9,10 @@ framework. This document explains how to use this new library. | ||||
| Migration plan | ||||
| ============== | ||||
|  | ||||
| ``django.newforms`` currently is only available in the Django development version | ||||
| -- i.e., it's not available in the Django 0.95 release. For the next Django | ||||
| release, our plan is to do the following: | ||||
| ``django.newforms`` currently is only available in Django beginning | ||||
| with the 0.96 release.  the Django development version -- i.e., it's | ||||
| not available in the Django 0.95 release. For the next Django release, | ||||
| our plan is to do the following: | ||||
|  | ||||
|     * As of revision [4208], we've copied the current ``django.forms`` to | ||||
|       ``django.oldforms``. This allows you to upgrade your code *now* rather | ||||
|   | ||||
| @@ -17,6 +17,113 @@ next official release; then you'll be able to upgrade in one step | ||||
| instead of needing to make incremental changes to keep up with the | ||||
| development version of Django. | ||||
|  | ||||
| Backwards-incompatible changes | ||||
| ============================== | ||||
|  | ||||
| The following changes may require you to update your code when you switch from | ||||
| 0.95 to 0.96: | ||||
|  | ||||
| ``MySQLdb`` version requirement | ||||
| ------------------------------- | ||||
|  | ||||
| Due to a bug in older versions of the ``MySQLdb`` Python module (which | ||||
| Django uses to connect to MySQL databases), Django's MySQL backend now | ||||
| requires version 1.2.1p2 or higher of `MySQLdb`, and will raise | ||||
| exceptions if you attempt to use an older version. | ||||
|  | ||||
| If you're currently unable to upgrade your copy of ``MySQLdb`` to meet | ||||
| this requirement, a separate, backwards-compatible backend, called | ||||
| "mysql_old", has been added to Django. To use this backend, change | ||||
| the ``DATABASE_ENGINE`` setting in your Django settings file from | ||||
| this:: | ||||
|  | ||||
|     DATABASE_ENGINE = "mysql" | ||||
|  | ||||
| to this:: | ||||
|  | ||||
|     DATABASE_ENGINE = "mysql_old" | ||||
|  | ||||
| However, we strongly encourage MySQL users to upgrade to a more recent | ||||
| version of `MySQLdb` as soon as possible, The "mysql_old" backend is | ||||
| provided only to ease this transition, and is considered deprecated; | ||||
| aside from any necessary security fixes, it will not be actively | ||||
| maintained, and it will be removed in a future release of Django. | ||||
|  | ||||
| Also, note that some features, like the new ``DATABASE_OPTIONS`` | ||||
| setting (see the `databases documentation`_ for details), are only | ||||
| available on the "mysql" backend, and will not be made available for | ||||
| "mysql_old". | ||||
|  | ||||
| .. _databases documentation: ../databases/ | ||||
|  | ||||
| Database constraint names changed | ||||
| --------------------------------- | ||||
|  | ||||
| The format of the constraint names Django generates for foreign key | ||||
| references have changed slightly. These names are generally only used | ||||
| when it is not possible to put the reference directly on the affected | ||||
| column, so they is not always visible. | ||||
|  | ||||
| The effect of this change is that running ``manage.py reset`` and | ||||
| similar commands against an existing database may generate SQL with | ||||
| the new form of constraint name, while the database itself contains | ||||
| constraints named in the old form; this will cause the database server | ||||
| to raise an error message about modifying non-existent constraints. | ||||
|  | ||||
| If you need to work around this, there are two methods available: | ||||
|  | ||||
|     1. Redirect the output of ``manage.py`` to a file, and edit the | ||||
|        generated SQL to use the correct constraint names before | ||||
|        executing it. | ||||
|  | ||||
|     2. Examine the output of ``manage.py sqlall`` to see the new-style | ||||
|        constraint names, and use that as a guide to rename existing | ||||
|        constraints in your database. | ||||
|  | ||||
| Name changes in ``manage.py`` | ||||
| ----------------------------- | ||||
|  | ||||
| A few of the options to ``manage.py`` have changed with the addition of fixture | ||||
| support: | ||||
|  | ||||
|     * There are new ``dumpdata`` and ``loaddata`` commands which, as | ||||
|       you might expect, will dump and load data to/from the | ||||
|       database. These commands can operate against any of Django's | ||||
|       supported serialization formats. | ||||
|  | ||||
|     * The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to | ||||
|       emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for | ||||
|       other custom SQL -- views, stored procedures, etc.). | ||||
|        | ||||
|     * The vestigial ``install`` command has been removed. Use ``syncdb``. | ||||
|  | ||||
| Backslash escaping changed | ||||
| -------------------------- | ||||
|  | ||||
| The Django database API now escapes backslashes given as query parameters. If | ||||
| you have any database API code that matches backslashes, and it was working before | ||||
| (despite the lack of escaping), you'll have to change your code to "unescape" the | ||||
| slashes one level. | ||||
|  | ||||
| For example, this used to work:: | ||||
|  | ||||
|     # Find text containing a single backslash | ||||
|     MyModel.objects.filter(text__contains='\\\\') | ||||
|  | ||||
| The above is now incorrect, and should be rewritten as:: | ||||
|  | ||||
|     # Find text containing a single backslash | ||||
|     MyModel.objects.filter(text__contains='\\') | ||||
|  | ||||
| Removed ENABLE_PSYCO setting | ||||
| ---------------------------- | ||||
|  | ||||
| The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes | ||||
| ``ENABLE_PSYCO`` it will have no effect; to use Psyco_, we recommend | ||||
| writing a middleware class to activate it. | ||||
|  | ||||
| .. _psyco: http://psyco.sourceforge.net/ | ||||
|  | ||||
| What's new in 0.96? | ||||
| =================== | ||||
|  | ||||
| @@ -130,113 +237,6 @@ A small change, but a very nice one: dedicated views for adding and | ||||
| updating users have been added to the admin interface, so you no | ||||
| longer need to worry about working with hashed passwords in the admin. | ||||
|  | ||||
| Backwards-incompatible changes | ||||
| ============================== | ||||
|  | ||||
| The following changes may require you to update your code when you switch from | ||||
| 0.95 to 0.96: | ||||
|  | ||||
| `MySQLdb` version requirement | ||||
| ----------------------------- | ||||
|  | ||||
| Due to a bug in older versions of the `MySQLdb` Python module (which | ||||
| Django uses to connect to MySQL databases), Django's MySQL backend now | ||||
| requires version 1.2.1p2 or higher of `MySQLdb`, and will raise | ||||
| exceptions if you attempt to use an older version. | ||||
|  | ||||
| If you're currently unable to upgrade your copy of `MySQLdb` to meet | ||||
| this requirement, a separate, backwards-compatible backend, called | ||||
| "mysql_old", has been added to Django. To use this backend, change | ||||
| the ``DATABASE_ENGINE`` setting in your Django settings file from | ||||
| this:: | ||||
|  | ||||
|     DATABASE_ENGINE = "mysql" | ||||
|  | ||||
| to this:: | ||||
|  | ||||
|     DATABASE_ENGINE = "mysql_old" | ||||
|  | ||||
| However, we strongly encourage MySQL users to upgrade to a more recent | ||||
| version of `MySQLdb` as soon as possible, The "mysql_old" backend is | ||||
| provided only to ease this transition, and is considered deprecated; | ||||
| aside from any necessary security fixes, it will not be actively | ||||
| maintained, and it will be removed in a future release of Django. | ||||
|  | ||||
| Also, note that some features, like the new ``DATABASE_OPTIONS`` | ||||
| setting (see the `databases documentation`_ for details), are only | ||||
| available on the "mysql" backend, and will not be made available for | ||||
| "mysql_old". | ||||
|  | ||||
| .. _databases: ../databases/ | ||||
|  | ||||
| Database constraint names changed | ||||
| --------------------------------- | ||||
|  | ||||
| The format of the constraint names Django generates for foreign key | ||||
| references have changed slightly. These names are generally only used | ||||
| when it is not possible to put the reference directly on the affected | ||||
| column, so they is not always visible. | ||||
|  | ||||
| The effect of this change is that running ``manage.py reset`` and | ||||
| similar commands against an existing database may generate SQL with | ||||
| the new form of constraint name, while the database itself contains | ||||
| constraints named in the old form; this will cause the database server | ||||
| to raise an error message about modifying non-existent constraints. | ||||
|  | ||||
| If you need to work around this, there are two methods available: | ||||
|  | ||||
|     1. Redirect the output of ``manage.py`` to a file, and edit the | ||||
|        generated SQL to use the correct constraint names before | ||||
|        executing it. | ||||
|  | ||||
|     2. Examine the output of ``manage.py sqlall`` to see the new-style | ||||
|        constraint names, and use that as a guide to rename existing | ||||
|        constraints in your database. | ||||
|  | ||||
| Names changes in ``manage.py`` | ||||
| ------------------------------ | ||||
|  | ||||
| A few of the options to ``manage.py`` have changed with the addition of fixture | ||||
| support: | ||||
|  | ||||
|     * There are new ``dumpdata`` and ``loaddata`` commands which, as | ||||
|       you might expect, will dump and load data to/from the | ||||
|       database. These commands can operate against any of Django's | ||||
|       supported serialization formats. | ||||
|  | ||||
|     * The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to | ||||
|       emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for | ||||
|       other custom SQL -- views, stored procedures, etc.). | ||||
|        | ||||
|     * The vestigial ``install`` command has been removed. Use ``syncdb``. | ||||
|  | ||||
| Backslash escaping changed | ||||
| -------------------------- | ||||
|  | ||||
| The Django database API now escapes backslashes given as query parameters. If | ||||
| you have any database API code that matches backslashes, and it was working before | ||||
| (despite the lack of escaping), you'll have to change your code to "unescape" the | ||||
| slashes one level. | ||||
|  | ||||
| For example, this used to work:: | ||||
|  | ||||
|     # Find text containing a single backslash | ||||
|     MyModel.objects.filter(text__contains='\\\\') | ||||
|  | ||||
| The above is now incorrect, and should be rewritten as:: | ||||
|  | ||||
|     # Find text containing a single backslash | ||||
|     MyModel.objects.filter(text__contains='\\') | ||||
|  | ||||
| Removed ENABLE_PSYCO setting | ||||
| ---------------------------- | ||||
|  | ||||
| The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes | ||||
| ``ENABLE_PSYCO`` it will have no effect; to use Psyco, we recommend | ||||
| writing a middleware class to activate it. | ||||
|  | ||||
| .. _psyco: http://psyco.sourceforge.net/ | ||||
|  | ||||
| Thanks | ||||
| ====== | ||||
|  | ||||
|   | ||||
| @@ -384,7 +384,6 @@ Methods | ||||
|     Deletes the cookie with the given key. Fails silently if the key doesn't | ||||
|     exist. | ||||
|  | ||||
|     The ``path`` and ``domain`` arguments are new in the Django development version. | ||||
|     Due to the way cookies work, ``path`` and ``domain`` should be the same | ||||
|     values you used in ``set_cookie()`` -- otherwise the cookie may not be deleted. | ||||
|  | ||||
|   | ||||
| @@ -265,8 +265,6 @@ The name of the cookie to use for sessions. This can be whatever you want. | ||||
| SESSION_COOKIE_SECURE | ||||
| --------------------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Default: ``False`` | ||||
|  | ||||
| Whether to use a secure cookie for the session cookie. If this is set to | ||||
|   | ||||
| @@ -429,8 +429,6 @@ trailing space. | ||||
| FIXTURE_DIRS | ||||
| ------------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Default: ``()`` (Empty tuple) | ||||
|  | ||||
| List of locations of the fixture data files, in search order. Note that | ||||
| @@ -716,8 +714,6 @@ See the `session docs`_. | ||||
| SESSION_COOKIE_SECURE | ||||
| --------------------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Default: ``False`` | ||||
|  | ||||
| Whether to use a secure cookie for the session cookie. If this is set to | ||||
| @@ -812,8 +808,6 @@ misspelled) variables. See `How invalid variables are handled`_. | ||||
| TEST_RUNNER | ||||
| ----------- | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Default: ``'django.test.simple.run_tests'`` | ||||
|  | ||||
| The name of the method to use for starting the test suite. See  | ||||
| @@ -824,8 +818,6 @@ The name of the method to use for starting the test suite. See | ||||
| TEST_DATABASE_NAME | ||||
| ------------------ | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| Default: ``None`` | ||||
|  | ||||
| The name of database to use when running the test suite. If a value of  | ||||
|   | ||||
| @@ -112,8 +112,6 @@ know how to write Python code. | ||||
| Comments | ||||
| ======== | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| To comment-out part of a template, use the comment syntax: ``{# #}``. | ||||
|  | ||||
| For example, this template would render as ``'hello'``:: | ||||
| @@ -253,8 +251,8 @@ Here are some tips for working with inheritance: | ||||
|       if you want to add to the contents of a parent block instead of | ||||
|       completely overriding it. | ||||
|  | ||||
|     * **New in Django development version:** For extra readability, you can | ||||
|       optionally give a *name* to your ``{% endblock %}`` tag. For example:: | ||||
|     * For extra readability, you can optionally give a *name* to your | ||||
|       ``{% endblock %}`` tag. For example:: | ||||
|  | ||||
|           {% block content %} | ||||
|           ... | ||||
| @@ -548,9 +546,9 @@ The 'ifchanged' block tag is used within a loop. It has two possible uses. | ||||
|             <a href="{{ date|date:"M/d"|lower }}/">{{ date|date:"j" }}</a> | ||||
|         {% endfor %} | ||||
|  | ||||
| 2. **New in Django development version.** If given a variable, check whether that | ||||
|    variable has changed. For example, the following shows the date every time it | ||||
|    changes, but only shows the hour if both the hour and the date has changed:: | ||||
| 2. If given a variable, check whether that variable has changed. For | ||||
|    example, the following shows the date every time it changes, but | ||||
|    only shows the hour if both the hour and the date has changed:: | ||||
|  | ||||
|         {% for date in days %} | ||||
|             {% ifchanged date.date %} {{ date.date }} {% endifchanged %} | ||||
| @@ -828,13 +826,9 @@ The argument tells which template bit to output: | ||||
|     ``closecomment``    ``#}`` | ||||
|     ==================  ======= | ||||
|  | ||||
| Note: ``opencomment`` and ``closecomment`` are new in the Django development version. | ||||
|  | ||||
| url | ||||
| ~~~ | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| **Note that the syntax for this tag may change in the future, as we make it more robust.** | ||||
|  | ||||
| Returns an absolute URL (i.e., a URL without the domain name) matching a given | ||||
| @@ -976,8 +970,6 @@ place -- but only if there's a decimal part to be displayed. For example: | ||||
|     * ``36.15`` gets converted to ``36.2`` | ||||
|     * ``36`` gets converted to ``36`` | ||||
|  | ||||
| **New in Django development version** | ||||
|  | ||||
| If used with a numeric integer argument, ``floatformat`` rounds a number to that  | ||||
| many decimal places.  For example: | ||||
|  | ||||
|   | ||||
| @@ -2,8 +2,6 @@ | ||||
| Testing Django applications | ||||
| =========================== | ||||
|  | ||||
| **New in Django development version**. | ||||
|  | ||||
| Automated testing is an extremely useful weapon in the bug-killing arsenal | ||||
| of the modern developer. When initially writing code, a test suite can be | ||||
| used to validate that code behaves as expected. When refactoring or | ||||
|   | ||||
| @@ -400,8 +400,6 @@ to pass metadata and options to views. | ||||
| Passing extra options to ``include()`` | ||||
| -------------------------------------- | ||||
|  | ||||
| **New in Django development version.** | ||||
|  | ||||
| Similarly, you can pass extra options to ``include()``. When you pass extra | ||||
| options to ``include()``, *each* line in the included URLconf will be passed | ||||
| the extra options. | ||||
| @@ -442,8 +440,6 @@ every view in the the included URLconf accepts the extra options you're passing. | ||||
| Passing callable objects instead of strings | ||||
| =========================================== | ||||
|  | ||||
| **New in Django development version.** | ||||
|  | ||||
| Some developers find it more natural to pass the actual Python function object | ||||
| rather than a string containing the path to its module. This alternative is | ||||
| supported -- you can pass any callable object as the view. | ||||
|   | ||||
		Reference in New Issue
	
	Block a user