<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Django 1.5 alpha release notes — Django 1.5.9 documentation</title> <link rel="stylesheet" href="../_static/default.css" type="text/css" /> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" /> <script type="text/javascript"> var DOCUMENTATION_OPTIONS = { URL_ROOT: '../', VERSION: '1.5.9', COLLAPSE_INDEX: false, FILE_SUFFIX: '.html', HAS_SOURCE: true }; </script> <script type="text/javascript" src="../_static/jquery.js"></script> <script type="text/javascript" src="../_static/underscore.js"></script> <script type="text/javascript" src="../_static/doctools.js"></script> <link rel="top" title="Django 1.5.9 documentation" href="../index.html" /> <link rel="up" title="Release notes" href="index.html" /> <link rel="next" title="Django 1.4 beta release notes" href="1.4-beta-1.html" /> <link rel="prev" title="Django 1.5 beta release notes" href="1.5-beta-1.html" /> <script type="text/javascript" src="../templatebuiltins.js"></script> <script type="text/javascript"> (function($) { if (!django_template_builtins) { // templatebuiltins.js missing, do nothing. return; } $(document).ready(function() { // Hyperlink Django template tags and filters var base = "../ref/templates/builtins.html"; if (base == "#") { // Special case for builtins.html itself base = ""; } // Tags are keywords, class '.k' $("div.highlight\\-html\\+django span.k").each(function(i, elem) { var tagname = $(elem).text(); if ($.inArray(tagname, django_template_builtins.ttags) != -1) { var fragment = tagname.replace(/_/, '-'); $(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>"); } }); // Filters are functions, class '.nf' $("div.highlight\\-html\\+django span.nf").each(function(i, elem) { var filtername = $(elem).text(); if ($.inArray(filtername, django_template_builtins.tfilters) != -1) { var fragment = filtername.replace(/_/, '-'); $(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>"); } }); }); })(jQuery); </script> </head> <body> <div class="document"> <div id="custom-doc" class="yui-t6"> <div id="hd"> <h1><a href="../index.html">Django 1.5.9 documentation</a></h1> <div id="global-nav"> <a title="Home page" href="../index.html">Home</a> | <a title="Table of contents" href="../contents.html">Table of contents</a> | <a title="Global index" href="../genindex.html">Index</a> | <a title="Module index" href="../py-modindex.html">Modules</a> </div> <div class="nav"> « <a href="1.5-beta-1.html" title="Django 1.5 beta release notes">previous</a> | <a href="index.html" title="Release notes" accesskey="U">up</a> | <a href="1.4-beta-1.html" title="Django 1.4 beta release notes">next</a> »</div> </div> <div id="bd"> <div id="yui-main"> <div class="yui-b"> <div class="yui-g" id="releases-1.5-alpha-1"> <div class="section" id="s-django-1-5-alpha-release-notes"> <span id="django-1-5-alpha-release-notes"></span><h1>Django 1.5 alpha release notes<a class="headerlink" href="#django-1-5-alpha-release-notes" title="Permalink to this headline">¶</a></h1> <p>October 25, 2012.</p> <p>Welcome to Django 1.5 alpha!</p> <p>This is the first in a series of preview/development releases leading up to the eventual release of Django 1.5, scheduled for December 2012. This release is primarily targeted at developers who are interested in trying out new features and testing the Django codebase to help identify and resolve bugs prior to the final 1.5 release.</p> <p>As such, this release is <em>not</em> intended for production use, and any such use is discouraged.</p> <p>In particular, we need the community’s help to test Django 1.5’s new <a class="reference internal" href="#python-3-support">Python 3 support</a> – not just to report bugs on Python 3, but also regressions on Python 2. While Django is very conservative with regards to backwards compatibility, mistakes are always possible, and it’s likely that the Python 3 refactoring work introduced some regressions.</p> <p>Django 1.5 alpha includes various <a class="reference internal" href="#what-s-new-in-django-1-5">new features</a> and some minor <a class="reference internal" href="#backwards-incompatible-changes-in-1-5">backwards incompatible changes</a>. There are also some features that have been dropped, which are detailed in <a class="reference internal" href="../internals/deprecation.html"><em>our deprecation plan</em></a>, and we’ve <a class="reference internal" href="#features-deprecated-in-1-5">begun the deprecation process for some features</a>.</p> <div class="section" id="s-overview"> <span id="overview"></span><h2>Overview<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2> <p>The biggest new feature in Django 1.5 is the <a class="reference internal" href="#configurable-user-model">configurable User model</a>. Before Django 1.5, applications that wanted to use Django’s auth framework (<a class="reference internal" href="../topics/auth/index.html#module-django.contrib.auth" title="django.contrib.auth: Django's authentication framework."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.auth</span></tt></a>) were forced to use Django’s definition of a “user”. In Django 1.5, you can now swap out the <tt class="docutils literal"><span class="pre">User</span></tt> model for one that you write yourself. This could be a simple extension to the existing <tt class="docutils literal"><span class="pre">User</span></tt> model – for example, you could add a Twitter or Facebook ID field – or you could completely replace the <tt class="docutils literal"><span class="pre">User</span></tt> with one totally customized for your site.</p> <p>Django 1.5 is also the first release with <a class="reference internal" href="#python-3-support">Python 3 support</a>! We’re labeling this support “experimental” because we don’t yet consider it production-ready, but everything’s in place for you to start porting your apps to Python 3. Our next release, Django 1.6, will support Python 3 without reservations.</p> <p>Other notable new features in Django 1.5 include:</p> <ul class="simple"> <li><a class="reference internal" href="#support-for-saving-a-subset-of-model-s-fields">Support for saving a subset of model’s fields</a> - <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><tt class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></tt></a> now accepts an <tt class="docutils literal"><span class="pre">update_fields</span></tt> argument, letting you specify which fields are written back to the database when you call <tt class="docutils literal"><span class="pre">save()</span></tt>. This can help in high-concurrency operations, and can improve performance.</li> <li>Better <a class="reference external" href="#explicit-streaming-responses">support for streaming responses</a> via the new <a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a> response class.</li> <li><a class="reference internal" href="#geodjango">GeoDjango</a> now supports PostGIS 2.0.</li> <li>... and more; <a class="reference external" href="#what-s-new-in-django-1-5">see below</a>.</li> </ul> <p>Wherever possible we try to introduce new features in a backwards-compatible manner per <a class="reference internal" href="../misc/api-stability.html"><em>our API stability policy</em></a> policy. However, as with previous releases, Django 1.5 ships with some minor <a class="reference internal" href="#backwards-incompatible-changes-in-1-5">backwards incompatible changes</a>; people upgrading from previous versions of Django should read that list carefully.</p> <p>One deprecated feature worth noting is the shift to “new-style” <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-url"><tt class="xref std std-ttag docutils literal"><span class="pre">url</span></tt></a> tag. Prior to Django 1.3, syntax like <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">myview</span> <span class="pre">%}</span></tt> was interpreted incorrectly (Django considered <tt class="docutils literal"><span class="pre">"myview"</span></tt> to be a literal name of a view, not a template variable named <tt class="docutils literal"><span class="pre">myview</span></tt>). Django 1.3 and above introduced the <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">url</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></tt> syntax to bring in the corrected behavior where <tt class="docutils literal"><span class="pre">myview</span></tt> was seen as a variable.</p> <p>The upshot of this is that if you are not using <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">url</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></tt> in your templates, you’ll need to change tags like <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">myview</span> <span class="pre">%}</span></tt> to <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">url</span> <span class="pre">"myview"</span> <span class="pre">%}</span></tt>. If you <em>were</em> using <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">url</span> <span class="pre">from</span> <span class="pre">future</span> <span class="pre">%}</span></tt> you can simply remove that line under Django 1.5</p> </div> <div class="section" id="s-python-compatibility"> <span id="python-compatibility"></span><h2>Python compatibility<a class="headerlink" href="#python-compatibility" title="Permalink to this headline">¶</a></h2> <p>Django 1.5 requires Python 2.6.5 or above, though we <strong>highly recommended</strong> Python 2.7.3 or above. Support for Python 2.5 and below has been dropped.</p> <p>This change should affect only a small number of Django users, as most operating-system vendors today are shipping Python 2.6 or newer as their default version. If you’re still using Python 2.5, however, you’ll need to stick to Django 1.4 until you can upgrade your Python version. Per <a class="reference internal" href="../internals/release-process.html"><em>our support policy</em></a>, Django 1.4 will continue to receive security support until the release of Django 1.6.</p> <p>Django 1.5 does not run on a Jython final release, because Jython’s latest release doesn’t currently support Python 2.6. However, Jython currently does offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha release.</p> <div class="section" id="s-python-3-support"> <span id="python-3-support"></span><h3>Python 3 support<a class="headerlink" href="#python-3-support" title="Permalink to this headline">¶</a></h3> <p>Django 1.5 introduces support for Python 3 - specifically, Python 3.2 and above. This comes in the form of a <strong>single</strong> codebase; you don’t need to install a different version of Django on Python 3. This means that you can write application targeted for just Python 2, just Python 3, or single applications that support both platforms.</p> <p>However, we’re labeling this support “experimental” for now: although it’s received extensive testing via our automated test suite, it’s received very little real-world testing. We’ve done our best to eliminate bugs, but we can’t be sure we covered all possible uses of Django. Further, Django’s more than a web framework; it’s an ecosystem of pluggable components. At this point, very few third-party applications have been ported to Python 3, so it’s unlikely that a real-world application will have all its dependencies satisfied under Python 3.</p> <p>Thus, we’re recommending that Django 1.5 not be used in production under Python 3. Instead, use this opportunity to begin <a class="reference internal" href="../topics/python3.html"><em>porting applications to Python 3</em></a>. If you’re an author of a pluggable component, we encourage you to start porting now.</p> <p>We plan to offer first-class, production-ready support for Python 3 in our next release, Django 1.6.</p> </div> </div> <div class="section" id="s-what-s-new-in-django-1-5"> <span id="what-s-new-in-django-1-5"></span><h2>What’s new in Django 1.5<a class="headerlink" href="#what-s-new-in-django-1-5" title="Permalink to this headline">¶</a></h2> <div class="section" id="s-configurable-user-model"> <span id="configurable-user-model"></span><h3>Configurable User model<a class="headerlink" href="#configurable-user-model" title="Permalink to this headline">¶</a></h3> <p>In Django 1.5, you can now use your own model as the store for user-related data. If your project needs a username with more than 30 characters, or if you want to store usernames in a format other than first name/last name, or you want to put custom profile information onto your User object, you can now do so.</p> <p>If you have a third-party reusable application that references the User model, you may need to make some changes to the way you reference User instances. You should also document any specific features of the User model that your application relies upon.</p> <p>See the <a class="reference internal" href="../topics/auth/customizing.html#auth-custom-user"><em>documentation on custom User models</em></a> for more details.</p> </div> <div class="section" id="s-support-for-saving-a-subset-of-model-s-fields"> <span id="support-for-saving-a-subset-of-model-s-fields"></span><h3>Support for saving a subset of model’s fields<a class="headerlink" href="#support-for-saving-a-subset-of-model-s-fields" title="Permalink to this headline">¶</a></h3> <p>The method <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><tt class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></tt></a> has a new keyword argument <tt class="docutils literal"><span class="pre">update_fields</span></tt>. By using this argument it is possible to save only a select list of model’s fields. This can be useful for performance reasons or when trying to avoid overwriting concurrent changes.</p> <p>Deferred instances (those loaded by .only() or .defer()) will automatically save just the loaded fields. If any field is set manually after load, that field will also get updated on save.</p> <p>See the <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.save" title="django.db.models.Model.save"><tt class="xref py py-meth docutils literal"><span class="pre">Model.save()</span></tt></a> documentation for more details.</p> </div> <div class="section" id="s-caching-of-related-model-instances"> <span id="caching-of-related-model-instances"></span><h3>Caching of related model instances<a class="headerlink" href="#caching-of-related-model-instances" title="Permalink to this headline">¶</a></h3> <p>When traversing relations, the ORM will avoid re-fetching objects that were previously loaded. For example, with the tutorial’s models:</p> <div class="highlight-python"><div class="highlight"><pre><span class="gp">>>> </span><span class="n">first_poll</span> <span class="o">=</span> <span class="n">Poll</span><span class="o">.</span><span class="n">objects</span><span class="o">.</span><span class="n">all</span><span class="p">()[</span><span class="mi">0</span><span class="p">]</span> <span class="gp">>>> </span><span class="n">first_choice</span> <span class="o">=</span> <span class="n">first_poll</span><span class="o">.</span><span class="n">choice_set</span><span class="o">.</span><span class="n">all</span><span class="p">()[</span><span class="mi">0</span><span class="p">]</span> <span class="gp">>>> </span><span class="n">first_choice</span><span class="o">.</span><span class="n">poll</span> <span class="ow">is</span> <span class="n">first_poll</span> <span class="go">True</span> </pre></div> </div> <p>In Django 1.5, the third line no longer triggers a new SQL query to fetch <tt class="docutils literal"><span class="pre">first_choice.poll</span></tt>; it was set by the second line.</p> <p>For one-to-one relationships, both sides can be cached. For many-to-one relationships, only the single side of the relationship can be cached. This is particularly helpful in combination with <tt class="docutils literal"><span class="pre">prefetch_related</span></tt>.</p> </div> <div class="section" id="s-explicit-support-for-streaming-responses"> <span id="explicit-support-for-streaming-responses"></span><h3>Explicit support for streaming responses<a class="headerlink" href="#explicit-support-for-streaming-responses" title="Permalink to this headline">¶</a></h3> <p>Before Django 1.5, it was possible to create a streaming response by passing an iterator to <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a>. But this was unreliable: any middleware that accessed the <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse.content" title="django.http.HttpResponse.content"><tt class="xref py py-attr docutils literal"><span class="pre">content</span></tt></a> attribute would consume the iterator prematurely.</p> <p>You can now explicitly generate a streaming response with the new <a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a> class. This class exposes a <a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse.streaming_content" title="django.http.StreamingHttpResponse.streaming_content"><tt class="xref py py-class docutils literal"><span class="pre">streaming_content</span></tt></a> attribute which is an iterator.</p> <p>Since <a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a> does not have a <tt class="docutils literal"><span class="pre">content</span></tt> attribute, middleware that needs access to the response content must test for streaming responses and behave accordingly. See <a class="reference internal" href="../topics/http/middleware.html#response-middleware"><em>process_response</em></a> for more information.</p> </div> <div class="section" id="s-verbatim-template-tag"> <span id="verbatim-template-tag"></span><h3><tt class="docutils literal"><span class="pre">{%</span> <span class="pre">verbatim</span> <span class="pre">%}</span></tt> template tag<a class="headerlink" href="#verbatim-template-tag" title="Permalink to this headline">¶</a></h3> <p>To make it easier to deal with javascript templates which collide with Django’s syntax, you can now use the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-verbatim"><tt class="xref std std-ttag docutils literal"><span class="pre">verbatim</span></tt></a> block tag to avoid parsing the tag’s content.</p> </div> <div class="section" id="s-retrieval-of-contenttype-instances-associated-with-proxy-models"> <span id="retrieval-of-contenttype-instances-associated-with-proxy-models"></span><h3>Retrieval of <tt class="docutils literal"><span class="pre">ContentType</span></tt> instances associated with proxy models<a class="headerlink" href="#retrieval-of-contenttype-instances-associated-with-proxy-models" title="Permalink to this headline">¶</a></h3> <p>The methods <a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.models.ContentTypeManager.get_for_model" title="django.contrib.contenttypes.models.ContentTypeManager.get_for_model"><tt class="xref py py-meth docutils literal"><span class="pre">ContentTypeManager.get_for_model()</span></tt></a> and <a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.models.ContentTypeManager.get_for_models" title="django.contrib.contenttypes.models.ContentTypeManager.get_for_models"><tt class="xref py py-meth docutils literal"><span class="pre">ContentTypeManager.get_for_models()</span></tt></a> have a new keyword argument – respectively <tt class="docutils literal"><span class="pre">for_concrete_model</span></tt> and <tt class="docutils literal"><span class="pre">for_concrete_models</span></tt>. By passing <tt class="docutils literal"><span class="pre">False</span></tt> using this argument it is now possible to retrieve the <a class="reference internal" href="../ref/contrib/contenttypes.html#django.contrib.contenttypes.models.ContentType" title="django.contrib.contenttypes.models.ContentType"><tt class="xref py py-class docutils literal"><span class="pre">ContentType</span></tt></a> associated with proxy models.</p> </div> <div class="section" id="s-new-view-variable-in-class-based-views-context"> <span id="new-view-variable-in-class-based-views-context"></span><h3>New <tt class="docutils literal"><span class="pre">view</span></tt> variable in class-based views context<a class="headerlink" href="#new-view-variable-in-class-based-views-context" title="Permalink to this headline">¶</a></h3> <p>In all <a class="reference internal" href="../topics/class-based-views/index.html"><em>generic class-based views</em></a> (or any class-based view inheriting from <tt class="docutils literal"><span class="pre">ContextMixin</span></tt>), the context dictionary contains a <tt class="docutils literal"><span class="pre">view</span></tt> variable that points to the <tt class="docutils literal"><span class="pre">View</span></tt> instance.</p> </div> <div class="section" id="s-geodjango"> <span id="geodjango"></span><h3>GeoDjango<a class="headerlink" href="#geodjango" title="Permalink to this headline">¶</a></h3> <ul class="simple"> <li><a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.LineString" title="django.contrib.gis.geos.LineString"><tt class="xref py py-class docutils literal"><span class="pre">LineString</span></tt></a> and <a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.MultiLineString" title="django.contrib.gis.geos.MultiLineString"><tt class="xref py py-class docutils literal"><span class="pre">MultiLineString</span></tt></a> GEOS objects now support the <a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry.interpolate" title="django.contrib.gis.geos.GEOSGeometry.interpolate"><tt class="xref py py-meth docutils literal"><span class="pre">interpolate()</span></tt></a> and <a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry.project" title="django.contrib.gis.geos.GEOSGeometry.project"><tt class="xref py py-meth docutils literal"><span class="pre">project()</span></tt></a> methods (so-called linear referencing).</li> <li>The <tt class="docutils literal"><span class="pre">wkb</span></tt> and <tt class="docutils literal"><span class="pre">hex</span></tt> properties of <a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry" title="django.contrib.gis.geos.GEOSGeometry"><tt class="xref py py-class docutils literal"><span class="pre">GEOSGeometry</span></tt></a> objects preserve the Z dimension.</li> <li>Support for PostGIS 2.0 has been added and support for GDAL < 1.5 has been dropped.</li> </ul> </div> <div class="section" id="s-minor-features"> <span id="minor-features"></span><h3>Minor features<a class="headerlink" href="#minor-features" title="Permalink to this headline">¶</a></h3> <p>Django 1.5 also includes several smaller improvements worth noting:</p> <ul class="simple"> <li>The template engine now interprets <tt class="docutils literal"><span class="pre">True</span></tt>, <tt class="docutils literal"><span class="pre">False</span></tt> and <tt class="docutils literal"><span class="pre">None</span></tt> as the corresponding Python objects.</li> <li><a class="reference internal" href="../ref/utils.html#module-django.utils.timezone" title="django.utils.timezone: Timezone support."><tt class="xref py py-mod docutils literal"><span class="pre">django.utils.timezone</span></tt></a> provides a helper for converting aware datetimes between time zones. See <a class="reference internal" href="../ref/utils.html#django.utils.timezone.localtime" title="django.utils.timezone.localtime"><tt class="xref py py-func docutils literal"><span class="pre">localtime()</span></tt></a>.</li> <li>The generic views support OPTIONS requests.</li> <li>Management commands do not raise <tt class="docutils literal"><span class="pre">SystemExit</span></tt> any more when called by code from <a class="reference internal" href="../ref/django-admin.html#call-command"><em>call_command</em></a>. Any exception raised by the command (mostly <a class="reference internal" href="../howto/custom-management-commands.html#ref-command-exceptions"><em>CommandError</em></a>) is propagated.</li> <li>The dumpdata management command outputs one row at a time, preventing out-of-memory errors when dumping large datasets.</li> <li>In the localflavor for Canada, “pq” was added to the acceptable codes for Quebec. It’s an old abbreviation.</li> <li>The <a class="reference internal" href="../topics/signals.html#connecting-receiver-functions"><em>receiver</em></a> decorator is now able to connect to more than one signal by supplying a list of signals.</li> <li>In the admin, you can now filter users by groups which they are members of.</li> <li><a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.bulk_create" title="django.db.models.query.QuerySet.bulk_create"><tt class="xref py py-meth docutils literal"><span class="pre">QuerySet.bulk_create()</span></tt></a> now has a batch_size argument. By default the batch_size is unlimited except for SQLite where single batch is limited so that 999 parameters per query isn’t exceeded.</li> <li>The <a class="reference internal" href="../ref/settings.html#std:setting-LOGIN_URL"><tt class="xref std std-setting docutils literal"><span class="pre">LOGIN_URL</span></tt></a> and <a class="reference internal" href="../ref/settings.html#std:setting-LOGIN_REDIRECT_URL"><tt class="xref std std-setting docutils literal"><span class="pre">LOGIN_REDIRECT_URL</span></tt></a> settings now also accept view function names and <a class="reference internal" href="../topics/http/urls.html#naming-url-patterns"><em>named URL patterns</em></a>. This allows you to reduce configuration duplication. More information can be found in the <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.decorators.login_required" title="django.contrib.auth.decorators.login_required"><tt class="xref py py-func docutils literal"><span class="pre">login_required()</span></tt></a> documentation.</li> <li>Django now provides a mod_wsgi <a class="reference internal" href="../howto/deployment/wsgi/apache-auth.html"><em>auth handler</em></a>.</li> <li>The <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.delete" title="django.db.models.query.QuerySet.delete"><tt class="xref py py-meth docutils literal"><span class="pre">QuerySet.delete()</span></tt></a> and <a class="reference internal" href="../ref/models/instances.html#django.db.models.Model.delete" title="django.db.models.Model.delete"><tt class="xref py py-meth docutils literal"><span class="pre">Model.delete()</span></tt></a> can now take fast-path in some cases. The fast-path allows for less queries and less objects fetched into memory. See <a class="reference internal" href="../ref/models/querysets.html#django.db.models.query.QuerySet.delete" title="django.db.models.query.QuerySet.delete"><tt class="xref py py-meth docutils literal"><span class="pre">QuerySet.delete()</span></tt></a> for details.</li> <li>An instance of <a class="reference internal" href="../ref/urlresolvers.html#django.core.urlresolvers.ResolverMatch" title="django.core.urlresolvers.ResolverMatch"><tt class="xref py py-class docutils literal"><span class="pre">ResolverMatch</span></tt></a> is stored on the request as <tt class="docutils literal"><span class="pre">resolver_match</span></tt>.</li> <li>By default, all logging messages reaching the <tt class="docutils literal"><span class="pre">django</span></tt> logger when <a class="reference internal" href="../ref/settings.html#std:setting-DEBUG"><tt class="xref std std-setting docutils literal"><span class="pre">DEBUG</span></tt></a> is <tt class="docutils literal"><span class="pre">True</span></tt> are sent to the console (unless you redefine the logger in your <a class="reference internal" href="../ref/settings.html#std:setting-LOGGING"><tt class="xref std std-setting docutils literal"><span class="pre">LOGGING</span></tt></a> setting).</li> <li>When using <a class="reference internal" href="../ref/templates/api.html#django.template.RequestContext" title="django.template.RequestContext"><tt class="xref py py-class docutils literal"><span class="pre">RequestContext</span></tt></a>, it is now possible to look up permissions by using <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">if</span> <span class="pre">'someapp.someperm'</span> <span class="pre">in</span> <span class="pre">perms</span> <span class="pre">%}</span></tt> in templates.</li> <li>It’s not required any more to have <tt class="docutils literal"><span class="pre">404.html</span></tt> and <tt class="docutils literal"><span class="pre">500.html</span></tt> templates in the root templates directory. Django will output some basic error messages for both situations when those templates are not found. Of course, it’s still recommended as good practice to provide those templates in order to present pretty error pages to the user.</li> <li><a class="reference internal" href="../topics/auth/index.html#module-django.contrib.auth" title="django.contrib.auth: Django's authentication framework."><tt class="xref py py-mod docutils literal"><span class="pre">django.contrib.auth</span></tt></a> provides a new signal that is emitted whenever a user fails to login successfully. See <a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.signals.user_login_failed" title="django.contrib.auth.signals.user_login_failed"><tt class="xref py py-data docutils literal"><span class="pre">user_login_failed</span></tt></a></li> <li>The loaddata management command now supports an <a class="reference internal" href="../ref/django-admin.html#django-admin-option---ignorenonexistent"><tt class="xref std std-djadminopt docutils literal"><span class="pre">--ignorenonexistent</span></tt></a> option to ignore data for fields that no longer exist.</li> <li><a class="reference internal" href="../topics/testing/overview.html#django.test.SimpleTestCase.assertXMLEqual" title="django.test.SimpleTestCase.assertXMLEqual"><tt class="xref py py-meth docutils literal"><span class="pre">assertXMLEqual()</span></tt></a> and <a class="reference internal" href="../topics/testing/overview.html#django.test.SimpleTestCase.assertXMLNotEqual" title="django.test.SimpleTestCase.assertXMLNotEqual"><tt class="xref py py-meth docutils literal"><span class="pre">assertXMLNotEqual()</span></tt></a> new assertions allow you to test equality for XML content at a semantic level, without caring for syntax differences (spaces, attribute order, etc.).</li> </ul> </div> </div> <div class="section" id="s-backwards-incompatible-changes-in-1-5"> <span id="backwards-incompatible-changes-in-1-5"></span><h2>Backwards incompatible changes in 1.5<a class="headerlink" href="#backwards-incompatible-changes-in-1-5" title="Permalink to this headline">¶</a></h2> <div class="admonition warning"> <p class="first admonition-title">Warning</p> <p class="last">In addition to the changes outlined in this section, be sure to review the <a class="reference internal" href="../internals/deprecation.html"><em>deprecation plan</em></a> for any features that have been removed. If you haven’t updated your code within the deprecation timeline for a given feature, its removal may appear as a backwards incompatible change.</p> </div> <div class="section" id="s-context-in-year-archive-class-based-views"> <span id="context-in-year-archive-class-based-views"></span><h3>Context in year archive class-based views<a class="headerlink" href="#context-in-year-archive-class-based-views" title="Permalink to this headline">¶</a></h3> <p>For consistency with the other date-based generic views, <a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.YearArchiveView" title="django.views.generic.dates.YearArchiveView"><tt class="xref py py-class docutils literal"><span class="pre">YearArchiveView</span></tt></a> now passes <tt class="docutils literal"><span class="pre">year</span></tt> in the context as a <a class="reference external" href="http://docs.python.org/2.7/library/datetime.html#datetime.date" title="(in Python v2.7)"><tt class="xref py py-class docutils literal"><span class="pre">datetime.date</span></tt></a> rather than a string. If you are using <tt class="docutils literal"><span class="pre">{{</span> <span class="pre">year</span> <span class="pre">}}</span></tt> in your templates, you must replace it with <tt class="docutils literal"><span class="pre">{{</span> <span class="pre">year|date:"Y"</span> <span class="pre">}}</span></tt>.</p> <p><tt class="docutils literal"><span class="pre">next_year</span></tt> and <tt class="docutils literal"><span class="pre">previous_year</span></tt> were also added in the context. They are calculated according to <tt class="docutils literal"><span class="pre">allow_empty</span></tt> and <tt class="docutils literal"><span class="pre">allow_future</span></tt>.</p> </div> <div class="section" id="s-context-in-year-and-month-archive-class-based-views"> <span id="context-in-year-and-month-archive-class-based-views"></span><h3>Context in year and month archive class-based views<a class="headerlink" href="#context-in-year-and-month-archive-class-based-views" title="Permalink to this headline">¶</a></h3> <p><a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.YearArchiveView" title="django.views.generic.dates.YearArchiveView"><tt class="xref py py-class docutils literal"><span class="pre">YearArchiveView</span></tt></a> and <a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.MonthArchiveView" title="django.views.generic.dates.MonthArchiveView"><tt class="xref py py-class docutils literal"><span class="pre">MonthArchiveView</span></tt></a> were documented to provide a <tt class="docutils literal"><span class="pre">date_list</span></tt> sorted in ascending order in the context, like their function-based predecessors, but it actually was in descending order. In 1.5, the documented order was restored. You may want to add (or remove) the <tt class="docutils literal"><span class="pre">reversed</span></tt> keyword when you’re iterating on <tt class="docutils literal"><span class="pre">date_list</span></tt> in a template:</p> <div class="highlight-python"><pre>{% for date in date_list reversed %}</pre> </div> <p><a class="reference internal" href="../ref/class-based-views/generic-date-based.html#django.views.generic.dates.ArchiveIndexView" title="django.views.generic.dates.ArchiveIndexView"><tt class="xref py py-class docutils literal"><span class="pre">ArchiveIndexView</span></tt></a> still provides a <tt class="docutils literal"><span class="pre">date_list</span></tt> in descending order.</p> </div> <div class="section" id="s-context-in-templateview"> <span id="context-in-templateview"></span><h3>Context in TemplateView<a class="headerlink" href="#context-in-templateview" title="Permalink to this headline">¶</a></h3> <p>For consistency with the design of the other generic views, <a class="reference internal" href="../ref/class-based-views/base.html#django.views.generic.base.TemplateView" title="django.views.generic.base.TemplateView"><tt class="xref py py-class docutils literal"><span class="pre">TemplateView</span></tt></a> no longer passes a <tt class="docutils literal"><span class="pre">params</span></tt> dictionary into the context, instead passing the variables from the URLconf directly into the context.</p> </div> <div class="section" id="s-non-form-data-in-http-requests"> <span id="non-form-data-in-http-requests"></span><h3>Non-form data in HTTP requests<a class="headerlink" href="#non-form-data-in-http-requests" title="Permalink to this headline">¶</a></h3> <p><a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.POST" title="django.http.HttpRequest.POST"><tt class="xref py py-attr docutils literal"><span class="pre">request.POST</span></tt></a> will no longer include data posted via HTTP requests with non form-specific content-types in the header. In prior versions, data posted with content-types other than <tt class="docutils literal"><span class="pre">multipart/form-data</span></tt> or <tt class="docutils literal"><span class="pre">application/x-www-form-urlencoded</span></tt> would still end up represented in the <a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.POST" title="django.http.HttpRequest.POST"><tt class="xref py py-attr docutils literal"><span class="pre">request.POST</span></tt></a> attribute. Developers wishing to access the raw POST data for these cases, should use the <a class="reference internal" href="../ref/request-response.html#django.http.HttpRequest.body" title="django.http.HttpRequest.body"><tt class="xref py py-attr docutils literal"><span class="pre">request.body</span></tt></a> attribute instead.</p> </div> <div class="section" id="s-options-put-and-delete-requests-in-the-test-client"> <span id="options-put-and-delete-requests-in-the-test-client"></span><h3>OPTIONS, PUT and DELETE requests in the test client<a class="headerlink" href="#options-put-and-delete-requests-in-the-test-client" title="Permalink to this headline">¶</a></h3> <p>Unlike GET and POST, these HTTP methods aren’t implemented by web browsers. Rather, they’re used in APIs, which transfer data in various formats such as JSON or XML. Since such requests may contain arbitrary data, Django doesn’t attempt to decode their body.</p> <p>However, the test client used to build a query string for OPTIONS and DELETE requests like for GET, and a request body for PUT requests like for POST. This encoding was arbitrary and inconsistent with Django’s behavior when it receives the requests, so it was removed in Django 1.5.</p> <p>If you were using the <tt class="docutils literal"><span class="pre">data</span></tt> parameter in an OPTIONS or a DELETE request, you must convert it to a query string and append it to the <tt class="docutils literal"><span class="pre">path</span></tt> parameter.</p> <p>If you were using the <tt class="docutils literal"><span class="pre">data</span></tt> parameter in a PUT request without a <tt class="docutils literal"><span class="pre">content_type</span></tt>, you must encode your data before passing it to the test client and set the <tt class="docutils literal"><span class="pre">content_type</span></tt> argument.</p> </div> <div class="section" id="s-system-version-of-simplejson-no-longer-used"> <span id="system-version-of-simplejson-no-longer-used"></span><h3>System version of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a> no longer used<a class="headerlink" href="#system-version-of-simplejson-no-longer-used" title="Permalink to this headline">¶</a></h3> <p>As explained below, Django 1.5 deprecates <tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt> in favor of Python 2.6’s built-in <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a> module. In theory, this change is harmless. Unfortunately, because of incompatibilities between versions of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a>, it may trigger errors in some circumstances.</p> <p>JSON-related features in Django 1.4 always used <tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt>. This module was actually:</p> <ul class="simple"> <li>A system version of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a>, if one was available (ie. <tt class="docutils literal"><span class="pre">import</span> <span class="pre">simplejson</span></tt> works), if it was more recent than Django’s built-in copy or it had the C speedups, or</li> <li>The <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a> module from the standard library, if it was available (ie. Python 2.6 or greater), or</li> <li>A built-in copy of version 2.0.7 of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a>.</li> </ul> <p>In Django 1.5, those features use Python’s <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a> module, which is based on version 2.0.9 of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a>.</p> <p>There are no known incompatibilities between Django’s copy of version 2.0.7 and Python’s copy of version 2.0.9. However, there are some incompatibilities between other versions of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a>:</p> <ul class="simple"> <li>While the <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a> API is documented as always returning unicode strings, the optional C implementation can return a byte string. This was fixed in Python 2.7.</li> <li><a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#simplejson.JSONEncoder" title="(in simplejson v3.6)"><tt class="xref py py-class docutils literal"><span class="pre">simplejson.JSONEncoder</span></tt></a> gained a <tt class="docutils literal"><span class="pre">namedtuple_as_object</span></tt> keyword argument in version 2.2.</li> </ul> <p>More information on these incompatibilities is available in <a class="reference external" href="https://code.djangoproject.com/ticket/18023#comment:10">ticket #18023</a>.</p> <p>The net result is that, if you have installed <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a> and your code uses Django’s serialization internals directly – for instance <tt class="docutils literal"><span class="pre">django.core.serializers.json.DjangoJSONEncoder</span></tt>, the switch from <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a> to <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a> could break your code. (In general, changes to internals aren’t documented; we’re making an exception here.)</p> <p>At this point, the maintainers of Django believe that using <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a> from the standard library offers the strongest guarantee of backwards-compatibility. They recommend to use it from now on.</p> </div> <div class="section" id="s-string-types-of-hasher-method-parameters"> <span id="string-types-of-hasher-method-parameters"></span><h3>String types of hasher method parameters<a class="headerlink" href="#string-types-of-hasher-method-parameters" title="Permalink to this headline">¶</a></h3> <p>If you have written a <a class="reference internal" href="../topics/auth/passwords.html#auth-password-storage"><em>custom password hasher</em></a>, your <tt class="docutils literal"><span class="pre">encode()</span></tt>, <tt class="docutils literal"><span class="pre">verify()</span></tt> or <tt class="docutils literal"><span class="pre">safe_summary()</span></tt> methods should accept Unicode parameters (<tt class="docutils literal"><span class="pre">password</span></tt>, <tt class="docutils literal"><span class="pre">salt</span></tt> or <tt class="docutils literal"><span class="pre">encoded</span></tt>). If any of the hashing methods need byte strings, you can use the <a class="reference internal" href="../ref/utils.html#django.utils.encoding.force_bytes" title="django.utils.encoding.force_bytes"><tt class="xref py py-func docutils literal"><span class="pre">force_bytes()</span></tt></a> utility to encode the strings.</p> </div> <div class="section" id="s-validation-of-previous-page-number-and-next-page-number"> <span id="validation-of-previous-page-number-and-next-page-number"></span><h3>Validation of previous_page_number and next_page_number<a class="headerlink" href="#validation-of-previous-page-number-and-next-page-number" title="Permalink to this headline">¶</a></h3> <p>When using <a class="reference internal" href="../topics/pagination.html"><em>object pagination</em></a>, the <tt class="docutils literal"><span class="pre">previous_page_number()</span></tt> and <tt class="docutils literal"><span class="pre">next_page_number()</span></tt> methods of the <a class="reference internal" href="../topics/pagination.html#django.core.paginator.Page" title="django.core.paginator.Page"><tt class="xref py py-class docutils literal"><span class="pre">Page</span></tt></a> object did not check if the returned number was inside the existing page range. It does check it now and raises an <a class="reference internal" href="../topics/pagination.html#django.core.paginator.InvalidPage" title="django.core.paginator.InvalidPage"><tt class="xref py py-exc docutils literal"><span class="pre">InvalidPage</span></tt></a> exception when the number is either too low or too high.</p> </div> <div class="section" id="s-behavior-of-autocommit-database-option-on-postgresql-changed"> <span id="behavior-of-autocommit-database-option-on-postgresql-changed"></span><h3>Behavior of autocommit database option on PostgreSQL changed<a class="headerlink" href="#behavior-of-autocommit-database-option-on-postgresql-changed" title="Permalink to this headline">¶</a></h3> <p>PostgreSQL’s autocommit option didn’t work as advertised previously. It did work for single transaction block, but after the first block was left the autocommit behavior was never restored. This bug is now fixed in 1.5. While this is only a bug fix, it is worth checking your applications behavior if you are using PostgreSQL together with the autocommit option.</p> </div> <div class="section" id="s-session-not-saved-on-500-responses"> <span id="session-not-saved-on-500-responses"></span><h3>Session not saved on 500 responses<a class="headerlink" href="#session-not-saved-on-500-responses" title="Permalink to this headline">¶</a></h3> <p>Django’s session middleware will skip saving the session data if the response’s status code is 500.</p> </div> <div class="section" id="s-email-checks-on-failed-admin-login"> <span id="email-checks-on-failed-admin-login"></span><h3>Email checks on failed admin login<a class="headerlink" href="#email-checks-on-failed-admin-login" title="Permalink to this headline">¶</a></h3> <p>Prior to Django 1.5, if you attempted to log into the admin interface and mistakenly used your email address instead of your username, the admin interface would provide a warning advising that your email address was not your username. In Django 1.5, the introduction of <a class="reference internal" href="../topics/auth/customizing.html#auth-custom-user"><em>custom User models</em></a> has required the removal of this warning. This doesn’t change the login behavior of the admin site; it only affects the warning message that is displayed under one particular mode of login failure.</p> </div> <div class="section" id="s-changes-in-tests-execution"> <span id="changes-in-tests-execution"></span><h3>Changes in tests execution<a class="headerlink" href="#changes-in-tests-execution" title="Permalink to this headline">¶</a></h3> <p>Some changes have been introduced in the execution of tests that might be backward-incompatible for some testing setups:</p> <div class="section" id="s-database-flushing-in-django-test-transactiontestcase"> <span id="database-flushing-in-django-test-transactiontestcase"></span><h4>Database flushing in <tt class="docutils literal"><span class="pre">django.test.TransactionTestCase</span></tt><a class="headerlink" href="#database-flushing-in-django-test-transactiontestcase" title="Permalink to this headline">¶</a></h4> <p>Previously, the test database was truncated <em>before</em> each test run in a <a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a>.</p> <p>In order to be able to run unit tests in any order and to make sure they are always isolated from each other, <a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> will now reset the database <em>after</em> each test run instead.</p> </div> <div class="section" id="s-no-more-implicit-db-sequences-reset"> <span id="no-more-implicit-db-sequences-reset"></span><h4>No more implicit DB sequences reset<a class="headerlink" href="#no-more-implicit-db-sequences-reset" title="Permalink to this headline">¶</a></h4> <p><a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> tests used to reset primary key sequences automatically together with the database flushing actions described above.</p> <p>This has been changed so no sequences are implicitly reset. This can cause <a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> tests that depend on hard-coded primary key values to break.</p> <p>The new <a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase.reset_sequences" title="django.test.TransactionTestCase.reset_sequences"><tt class="xref py py-attr docutils literal"><span class="pre">reset_sequences</span></tt></a> attribute can be used to force the old behavior for <a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> that might need it.</p> </div> <div class="section" id="s-ordering-of-tests"> <span id="ordering-of-tests"></span><h4>Ordering of tests<a class="headerlink" href="#ordering-of-tests" title="Permalink to this headline">¶</a></h4> <p>In order to make sure all <tt class="docutils literal"><span class="pre">TestCase</span></tt> code starts with a clean database, tests are now executed in the following order:</p> <ul class="simple"> <li>First, all unittests (including <a class="reference external" href="http://docs.python.org/2.7/library/unittest.html#unittest.TestCase" title="(in Python v2.7)"><tt class="xref py py-class docutils literal"><span class="pre">unittest.TestCase</span></tt></a>, <a class="reference internal" href="../topics/testing/overview.html#django.test.SimpleTestCase" title="django.test.SimpleTestCase"><tt class="xref py py-class docutils literal"><span class="pre">SimpleTestCase</span></tt></a>, <a class="reference internal" href="../topics/testing/overview.html#django.test.TestCase" title="django.test.TestCase"><tt class="xref py py-class docutils literal"><span class="pre">TestCase</span></tt></a> and <a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a>) are run with no particular ordering guaranteed nor enforced among them.</li> <li>Then any other tests (e.g. doctests) that may alter the database without restoring it to its original state are run.</li> </ul> <p>This should not cause any problems unless you have existing doctests which assume a <a class="reference internal" href="../topics/testing/overview.html#django.test.TransactionTestCase" title="django.test.TransactionTestCase"><tt class="xref py py-class docutils literal"><span class="pre">TransactionTestCase</span></tt></a> executed earlier left some database state behind or unit tests that rely on some form of state being preserved after the execution of other tests. Such tests are already very fragile, and must now be changed to be able to run independently.</p> </div> </div> <div class="section" id="s-cleaned-data-dictionary-kept-for-invalid-forms"> <span id="cleaned-data-dictionary-kept-for-invalid-forms"></span><h3><cite>cleaned_data</cite> dictionary kept for invalid forms<a class="headerlink" href="#cleaned-data-dictionary-kept-for-invalid-forms" title="Permalink to this headline">¶</a></h3> <p>The <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.cleaned_data" title="django.forms.Form.cleaned_data"><tt class="xref py py-attr docutils literal"><span class="pre">cleaned_data</span></tt></a> dictionary is now always present after form validation. When the form doesn’t validate, it contains only the fields that passed validation. You should test the success of the validation with the <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.is_valid" title="django.forms.Form.is_valid"><tt class="xref py py-meth docutils literal"><span class="pre">is_valid()</span></tt></a> method and not with the presence or absence of the <a class="reference internal" href="../ref/forms/api.html#django.forms.Form.cleaned_data" title="django.forms.Form.cleaned_data"><tt class="xref py py-attr docutils literal"><span class="pre">cleaned_data</span></tt></a> attribute on the form.</p> </div> <div class="section" id="s-miscellaneous"> <span id="miscellaneous"></span><h3>Miscellaneous<a class="headerlink" href="#miscellaneous" title="Permalink to this headline">¶</a></h3> <ul class="simple"> <li><a class="reference internal" href="../ref/forms/fields.html#django.forms.ModelMultipleChoiceField" title="django.forms.ModelMultipleChoiceField"><tt class="xref py py-class docutils literal"><span class="pre">django.forms.ModelMultipleChoiceField</span></tt></a> now returns an empty <tt class="docutils literal"><span class="pre">QuerySet</span></tt> as the empty value instead of an empty list.</li> <li><a class="reference internal" href="../ref/utils.html#django.utils.http.int_to_base36" title="django.utils.http.int_to_base36"><tt class="xref py py-func docutils literal"><span class="pre">int_to_base36()</span></tt></a> properly raises a <a class="reference external" href="http://docs.python.org/2.7/library/exceptions.html#exceptions.TypeError" title="(in Python v2.7)"><tt class="xref py py-exc docutils literal"><span class="pre">TypeError</span></tt></a> instead of <a class="reference external" href="http://docs.python.org/2.7/library/exceptions.html#exceptions.ValueError" title="(in Python v2.7)"><tt class="xref py py-exc docutils literal"><span class="pre">ValueError</span></tt></a> for non-integer inputs.</li> <li>The <tt class="docutils literal"><span class="pre">slugify</span></tt> template filter is now available as a standard python function at <a class="reference internal" href="../ref/utils.html#django.utils.text.slugify" title="django.utils.text.slugify"><tt class="xref py py-func docutils literal"><span class="pre">django.utils.text.slugify()</span></tt></a>. Similarly, <tt class="docutils literal"><span class="pre">remove_tags</span></tt> is available at <a class="reference internal" href="../ref/utils.html#django.utils.html.remove_tags" title="django.utils.html.remove_tags"><tt class="xref py py-func docutils literal"><span class="pre">django.utils.html.remove_tags()</span></tt></a>.</li> <li>Uploaded files are no longer created as executable by default. If you need them to be executable change <a class="reference internal" href="../ref/settings.html#std:setting-FILE_UPLOAD_PERMISSIONS"><tt class="xref std std-setting docutils literal"><span class="pre">FILE_UPLOAD_PERMISSIONS</span></tt></a> to your needs. The new default value is <tt class="docutils literal"><span class="pre">0666</span></tt> (octal) and the current umask value is first masked out.</li> <li>The <a class="reference internal" href="../topics/db/queries.html#query-expressions"><em>F() expressions</em></a> supported bitwise operators by <tt class="docutils literal"><span class="pre">&</span></tt> and <tt class="docutils literal"><span class="pre">|</span></tt>. These operators are now available using <tt class="docutils literal"><span class="pre">.bitand()</span></tt> and <tt class="docutils literal"><span class="pre">.bitor()</span></tt> instead. The removal of <tt class="docutils literal"><span class="pre">&</span></tt> and <tt class="docutils literal"><span class="pre">|</span></tt> was done to be consistent with <a class="reference internal" href="../topics/db/queries.html#complex-lookups-with-q"><em>Q() expressions</em></a> and <tt class="docutils literal"><span class="pre">QuerySet</span></tt> combining where the operators are used as boolean AND and OR operators.</li> <li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-csrf_token"><tt class="xref std std-ttag docutils literal"><span class="pre">csrf_token</span></tt></a> template tag is no longer enclosed in a div. If you need HTML validation against pre-HTML5 Strict DTDs, you should add a div around it in your pages.</li> </ul> </div> </div> <div class="section" id="s-features-deprecated-in-1-5"> <span id="features-deprecated-in-1-5"></span><h2>Features deprecated in 1.5<a class="headerlink" href="#features-deprecated-in-1-5" title="Permalink to this headline">¶</a></h2> <div class="section" id="s-auth-profile-module"> <span id="auth-profile-module"></span><h3><a class="reference internal" href="../ref/settings.html#std:setting-AUTH_PROFILE_MODULE"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a><a class="headerlink" href="#auth-profile-module" title="Permalink to this headline">¶</a></h3> <p>With the introduction of <a class="reference internal" href="../topics/auth/customizing.html#auth-custom-user"><em>custom User models</em></a>, there is no longer any need for a built-in mechanism to store user profile data.</p> <p>You can still define user profiles models that have a one-to-one relation with the User model - in fact, for many applications needing to associate data with a User account, this will be an appropriate design pattern to follow. However, the <a class="reference internal" href="../ref/settings.html#std:setting-AUTH_PROFILE_MODULE"><tt class="xref std std-setting docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a> setting, and the <a class="reference internal" href="../ref/contrib/auth.html#django.contrib.auth.models.User.get_profile" title="django.contrib.auth.models.User.get_profile"><tt class="xref py py-meth docutils literal"><span class="pre">get_profile()</span></tt></a> method for accessing the user profile model, should not be used any longer.</p> </div> <div class="section" id="s-streaming-behavior-of-httpresponse"> <span id="streaming-behavior-of-httpresponse"></span><h3>Streaming behavior of <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a><a class="headerlink" href="#streaming-behavior-of-httpresponse" title="Permalink to this headline">¶</a></h3> <p>Django 1.5 deprecates the ability to stream a response by passing an iterator to <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a>. If you rely on this behavior, switch to <a class="reference internal" href="../ref/request-response.html#django.http.StreamingHttpResponse" title="django.http.StreamingHttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">StreamingHttpResponse</span></tt></a>. See above for more details.</p> <p>In Django 1.7 and above, the iterator will be consumed immediately by <a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><tt class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></tt></a>.</p> </div> <div class="section" id="s-django-utils-simplejson"> <span id="django-utils-simplejson"></span><h3><tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt><a class="headerlink" href="#django-utils-simplejson" title="Permalink to this headline">¶</a></h3> <p>Since Django 1.5 drops support for Python 2.5, we can now rely on the <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a> module being available in Python’s standard library, so we’ve removed our own copy of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a>. You should now import <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a> instead of <tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt>.</p> <p>Unfortunately, this change might have unwanted side-effects, because of incompatibilities between versions of <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a> – see the backwards- incompatible changes section. If you rely on features added to <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a> after it became Python’s <a class="reference external" href="http://docs.python.org/2.7/library/json.html#json" title="(in Python v2.7)"><tt class="xref py py-mod docutils literal"><span class="pre">json</span></tt></a>, you should import <a class="reference external" href="http://simplejson.readthedocs.org/en/latest/index.html#module-simplejson" title="(in simplejson v3.6)"><tt class="xref py py-mod docutils literal"><span class="pre">simplejson</span></tt></a> explicitly.</p> </div> <div class="section" id="s-django-utils-encoding-strandunicode"> <span id="django-utils-encoding-strandunicode"></span><h3><tt class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></tt><a class="headerlink" href="#django-utils-encoding-strandunicode" title="Permalink to this headline">¶</a></h3> <p>The <a class="reference internal" href="../ref/utils.html#django.utils.encoding.StrAndUnicode" title="django.utils.encoding.StrAndUnicode"><tt class="xref py py-class docutils literal"><span class="pre">StrAndUnicode</span></tt></a> mix-in has been deprecated. Define a <tt class="docutils literal"><span class="pre">__str__</span></tt> method and apply the <a class="reference internal" href="../ref/utils.html#django.utils.encoding.python_2_unicode_compatible" title="django.utils.encoding.python_2_unicode_compatible"><tt class="xref py py-func docutils literal"><span class="pre">python_2_unicode_compatible()</span></tt></a> decorator instead.</p> </div> <div class="section" id="s-django-utils-itercompat-product"> <span id="django-utils-itercompat-product"></span><h3><tt class="docutils literal"><span class="pre">django.utils.itercompat.product</span></tt><a class="headerlink" href="#django-utils-itercompat-product" title="Permalink to this headline">¶</a></h3> <p>The <tt class="docutils literal"><span class="pre">django.utils.itercompat.product</span></tt> function has been deprecated. Use the built-in <a class="reference external" href="http://docs.python.org/2.7/library/itertools.html#itertools.product" title="(in Python v2.7)"><tt class="xref py py-func docutils literal"><span class="pre">itertools.product()</span></tt></a> instead.</p> </div> <div class="section" id="s-django-utils-markup"> <span id="django-utils-markup"></span><h3><tt class="docutils literal"><span class="pre">django.utils.markup</span></tt><a class="headerlink" href="#django-utils-markup" title="Permalink to this headline">¶</a></h3> <p>The markup contrib module has been deprecated and will follow an accelerated deprecation schedule. Direct use of python markup libraries or 3rd party tag libraries is preferred to Django maintaining this functionality in the framework.</p> </div> </div> </div> </div> </div> </div> <div class="yui-b" id="sidebar"> <div class="sphinxsidebar"> <div class="sphinxsidebarwrapper"> <h3><a href="../contents.html">Table Of Contents</a></h3> <ul> <li><a class="reference internal" href="#">Django 1.5 alpha release notes</a><ul> <li><a class="reference internal" href="#overview">Overview</a></li> <li><a class="reference internal" href="#python-compatibility">Python compatibility</a><ul> <li><a class="reference internal" href="#python-3-support">Python 3 support</a></li> </ul> </li> <li><a class="reference internal" href="#what-s-new-in-django-1-5">What’s new in Django 1.5</a><ul> <li><a class="reference internal" href="#configurable-user-model">Configurable User model</a></li> <li><a class="reference internal" href="#support-for-saving-a-subset-of-model-s-fields">Support for saving a subset of model’s fields</a></li> <li><a class="reference internal" href="#caching-of-related-model-instances">Caching of related model instances</a></li> <li><a class="reference internal" href="#explicit-support-for-streaming-responses">Explicit support for streaming responses</a></li> <li><a class="reference internal" href="#verbatim-template-tag"><tt class="docutils literal"><span class="pre">{%</span> <span class="pre">verbatim</span> <span class="pre">%}</span></tt> template tag</a></li> <li><a class="reference internal" href="#retrieval-of-contenttype-instances-associated-with-proxy-models">Retrieval of <tt class="docutils literal"><span class="pre">ContentType</span></tt> instances associated with proxy models</a></li> <li><a class="reference internal" href="#new-view-variable-in-class-based-views-context">New <tt class="docutils literal"><span class="pre">view</span></tt> variable in class-based views context</a></li> <li><a class="reference internal" href="#geodjango">GeoDjango</a></li> <li><a class="reference internal" href="#minor-features">Minor features</a></li> </ul> </li> <li><a class="reference internal" href="#backwards-incompatible-changes-in-1-5">Backwards incompatible changes in 1.5</a><ul> <li><a class="reference internal" href="#context-in-year-archive-class-based-views">Context in year archive class-based views</a></li> <li><a class="reference internal" href="#context-in-year-and-month-archive-class-based-views">Context in year and month archive class-based views</a></li> <li><a class="reference internal" href="#context-in-templateview">Context in TemplateView</a></li> <li><a class="reference internal" href="#non-form-data-in-http-requests">Non-form data in HTTP requests</a></li> <li><a class="reference internal" href="#options-put-and-delete-requests-in-the-test-client">OPTIONS, PUT and DELETE requests in the test client</a></li> <li><a class="reference internal" href="#system-version-of-simplejson-no-longer-used">System version of <tt class="docutils literal"><span class="pre">simplejson</span></tt> no longer used</a></li> <li><a class="reference internal" href="#string-types-of-hasher-method-parameters">String types of hasher method parameters</a></li> <li><a class="reference internal" href="#validation-of-previous-page-number-and-next-page-number">Validation of previous_page_number and next_page_number</a></li> <li><a class="reference internal" href="#behavior-of-autocommit-database-option-on-postgresql-changed">Behavior of autocommit database option on PostgreSQL changed</a></li> <li><a class="reference internal" href="#session-not-saved-on-500-responses">Session not saved on 500 responses</a></li> <li><a class="reference internal" href="#email-checks-on-failed-admin-login">Email checks on failed admin login</a></li> <li><a class="reference internal" href="#changes-in-tests-execution">Changes in tests execution</a><ul> <li><a class="reference internal" href="#database-flushing-in-django-test-transactiontestcase">Database flushing in <tt class="docutils literal"><span class="pre">django.test.TransactionTestCase</span></tt></a></li> <li><a class="reference internal" href="#no-more-implicit-db-sequences-reset">No more implicit DB sequences reset</a></li> <li><a class="reference internal" href="#ordering-of-tests">Ordering of tests</a></li> </ul> </li> <li><a class="reference internal" href="#cleaned-data-dictionary-kept-for-invalid-forms"><cite>cleaned_data</cite> dictionary kept for invalid forms</a></li> <li><a class="reference internal" href="#miscellaneous">Miscellaneous</a></li> </ul> </li> <li><a class="reference internal" href="#features-deprecated-in-1-5">Features deprecated in 1.5</a><ul> <li><a class="reference internal" href="#auth-profile-module"><tt class="docutils literal"><span class="pre">AUTH_PROFILE_MODULE</span></tt></a></li> <li><a class="reference internal" href="#streaming-behavior-of-httpresponse">Streaming behavior of <tt class="docutils literal"><span class="pre">HttpResponse</span></tt></a></li> <li><a class="reference internal" href="#django-utils-simplejson"><tt class="docutils literal"><span class="pre">django.utils.simplejson</span></tt></a></li> <li><a class="reference internal" href="#django-utils-encoding-strandunicode"><tt class="docutils literal"><span class="pre">django.utils.encoding.StrAndUnicode</span></tt></a></li> <li><a class="reference internal" href="#django-utils-itercompat-product"><tt class="docutils literal"><span class="pre">django.utils.itercompat.product</span></tt></a></li> <li><a class="reference internal" href="#django-utils-markup"><tt class="docutils literal"><span class="pre">django.utils.markup</span></tt></a></li> </ul> </li> </ul> </li> </ul> <h3>Browse</h3> <ul> <li>Prev: <a href="1.5-beta-1.html">Django 1.5 beta release notes</a></li> <li>Next: <a href="1.4-beta-1.html">Django 1.4 beta release notes</a></li> </ul> <h3>You are here:</h3> <ul> <li> <a href="../index.html">Django 1.5.9 documentation</a> <ul><li><a href="index.html">Release notes</a> <ul><li>Django 1.5 alpha release notes</li></ul> </li></ul> </li> </ul> <h3>This Page</h3> <ul class="this-page-menu"> <li><a href="../_sources/releases/1.5-alpha-1.txt" rel="nofollow">Show Source</a></li> </ul> <div id="searchbox" style="display: none"> <h3>Quick search</h3> <form class="search" action="../search.html" method="get"> <input type="text" name="q" /> <input type="submit" value="Go" /> <input type="hidden" name="check_keywords" value="yes" /> <input type="hidden" name="area" value="default" /> </form> <p class="searchtip" style="font-size: 90%"> Enter search terms or a module, class or function name. </p> </div> <script type="text/javascript">$('#searchbox').show(0);</script> </div> </div> <h3>Last update:</h3> <p class="topless">Aug 21, 2014</p> </div> </div> <div id="ft"> <div class="nav"> « <a href="1.5-beta-1.html" title="Django 1.5 beta release notes">previous</a> | <a href="index.html" title="Release notes" accesskey="U">up</a> | <a href="1.4-beta-1.html" title="Django 1.4 beta release notes">next</a> »</div> </div> </div> <div class="clearer"></div> </div> </body> </html>