<!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.3 alpha 1 release notes — Django 1.6.7 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.6.7',
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.6.7 documentation" href="../index.html" />
<link rel="up" title="Release notes" href="index.html" />
<link rel="next" title="Django 1.2 RC 1 release notes" href="1.2-rc-1.html" />
<link rel="prev" title="Django 1.3 beta 1 release notes" href="1.3-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.6.7 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.3-beta-1.html" title="Django 1.3 beta 1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.2-rc-1.html" title="Django 1.2 RC 1 release notes">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="releases-1.3-alpha-1">
<div class="section" id="s-django-1-3-alpha-1-release-notes">
<span id="django-1-3-alpha-1-release-notes"></span><h1>Django 1.3 alpha 1 release notes<a class="headerlink" href="#django-1-3-alpha-1-release-notes" title="Permalink to this headline">¶</a></h1>
<p>November 11, 2010</p>
<p>Welcome to Django 1.3 alpha 1!</p>
<p>This is the first in a series of preview/development releases leading
up to the eventual release of Django 1.3. 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.3 release.</p>
<p>As such, this release is <em>not</em> intended for production use, and any such use is
discouraged.</p>
<p>As of this alpha release, Django 1.3 contains a number of nifty <a class="reference internal" href="#what-s-new-in-django-1-3-alpha-1">new
features</a>, lots of bug fixes, some minor <a class="reference internal" href="#backwards-incompatible-changes-1-3-alpha-1">backwards incompatible
changes</a> and an easy upgrade path from Django 1.2.</p>
<div class="section" id="s-what-s-new-in-django-1-3-alpha-1">
<span id="what-s-new-in-django-1-3-alpha-1"></span><h2>What’s new in Django 1.3 alpha 1<a class="headerlink" href="#what-s-new-in-django-1-3-alpha-1" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-class-based-views">
<span id="class-based-views"></span><h3>Class-based views<a class="headerlink" href="#class-based-views" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 adds a framework that allows you to use a class as a view.
This means you can compose a view out of a collection of methods that
can be subclassed and overridden to provide common views of data without
having to write too much code.</p>
<p>Analogs of all the old function-based generic views have been provided,
along with a completely generic view base class that can be used as
the basis for reusable applications that can be easily extended.</p>
<p>See <a class="reference internal" href="../topics/class-based-views/index.html"><em>the documentation on Class-based Generic Views</em></a> for more details. There is also a document to
help you <a class="reference external" href="https://docs.djangoproject.com/en/1.4/topics/generic-views-migration/">convert your function-based generic views to class-based
views</a>.</p>
</div>
<div class="section" id="s-logging">
<span id="logging"></span><h3>Logging<a class="headerlink" href="#logging" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 adds framework-level support for Python’s logging module.
This means you can now easily configure and control logging as part of
your Django project. A number of logging handlers and logging calls
have been added to Django’s own code as well – most notably, the
error emails sent on a HTTP 500 server error are now handled as a
logging activity. See <a class="reference internal" href="../topics/logging.html"><em>the documentation on Django’s logging
interface</em></a> for more details.</p>
</div>
<div class="section" id="s-extended-static-files-handling">
<span id="extended-static-files-handling"></span><h3>Extended static files handling<a class="headerlink" href="#extended-static-files-handling" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 ships with a new contrib app <tt class="docutils literal"><span class="pre">'django.contrib.staticfiles'</span></tt>
to help developers handle the static media files (images, CSS, Javascript,
etc.) that are needed to render a complete web page.</p>
<p>In previous versions of Django, it was common to place static assets
in <a class="reference internal" href="../ref/settings.html#std:setting-MEDIA_ROOT"><tt class="xref std std-setting docutils literal"><span class="pre">MEDIA_ROOT</span></tt></a> along with user-uploaded files, and serve
them both at <a class="reference internal" href="../ref/settings.html#std:setting-MEDIA_URL"><tt class="xref std std-setting docutils literal"><span class="pre">MEDIA_URL</span></tt></a>. Part of the purpose of introducing
the <tt class="docutils literal"><span class="pre">staticfiles</span></tt> app is to make it easier to keep static files
separate from user-uploaded files. Static assets should now go in
<tt class="docutils literal"><span class="pre">static/</span></tt> subdirectories of your apps or in other static assets
directories listed in <a class="reference internal" href="../ref/settings.html#std:setting-STATICFILES_DIRS"><tt class="xref std std-setting docutils literal"><span class="pre">STATICFILES_DIRS</span></tt></a>, and will be served
at <a class="reference internal" href="../ref/settings.html#std:setting-STATIC_URL"><tt class="xref std std-setting docutils literal"><span class="pre">STATIC_URL</span></tt></a>.</p>
<p>See the <a class="reference internal" href="../ref/contrib/staticfiles.html"><em>reference documentation of the app</em></a>
for more details or learn how to <a class="reference internal" href="../howto/static-files/index.html"><em>manage static files</em></a>.</p>
</div>
<div class="section" id="s-unittest2-support">
<span id="unittest2-support"></span><h3><tt class="docutils literal"><span class="pre">unittest2</span></tt> support<a class="headerlink" href="#unittest2-support" title="Permalink to this headline">¶</a></h3>
<p>Python 2.7 introduced some major changes to the unittest library,
adding some extremely useful features. To ensure that every Django
project can benefit from these new features, Django ships with a
copy of <a class="reference external" href="http://pypi.python.org/pypi/unittest2">unittest2</a>, a copy of the Python 2.7 unittest library,
backported for Python 2.4 compatibility.</p>
<p>To access this library, Django provides the
<tt class="docutils literal"><span class="pre">django.utils.unittest</span></tt> module alias. If you are using Python
2.7, or you have installed unittest2 locally, Django will map the
alias to the installed version of the unittest library. Otherwise,
Django will use its own bundled version of unittest2.</p>
<p>To use this alias, simply use:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.utils</span> <span class="kn">import</span> <span class="n">unittest</span>
</pre></div>
</div>
<p>wherever you would have historically used:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">unittest</span>
</pre></div>
</div>
<p>If you want to continue to use the base unittest libary, you can –
you just won’t get any of the nice new unittest2 features.</p>
</div>
<div class="section" id="s-transaction-context-managers">
<span id="transaction-context-managers"></span><h3>Transaction context managers<a class="headerlink" href="#transaction-context-managers" title="Permalink to this headline">¶</a></h3>
<p>Users of Python 2.5 and above may now use transaction management functions as
<a class="reference external" href="http://docs.python.org/glossary.html#term-context-manager">context managers</a>. For example:</p>
<div class="highlight-python"><pre>with transaction.autocommit():
# ...</pre>
</div>
</div>
<div class="section" id="s-configurable-delete-cascade">
<span id="configurable-delete-cascade"></span><h3>Configurable delete-cascade<a class="headerlink" href="#configurable-delete-cascade" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey" title="django.db.models.ForeignKey"><tt class="xref py py-class docutils literal"><span class="pre">ForeignKey</span></tt></a> and
<a class="reference internal" href="../ref/models/fields.html#django.db.models.OneToOneField" title="django.db.models.OneToOneField"><tt class="xref py py-class docutils literal"><span class="pre">OneToOneField</span></tt></a> now accept an
<a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey.on_delete" title="django.db.models.ForeignKey.on_delete"><tt class="xref py py-attr docutils literal"><span class="pre">on_delete</span></tt></a> argument to customize behavior
when the referenced object is deleted. Previously, deletes were always
cascaded; available alternatives now include set null, set default, set to any
value, protect, or do nothing.</p>
<p>For more information, see the <a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey.on_delete" title="django.db.models.ForeignKey.on_delete"><tt class="xref py py-attr docutils literal"><span class="pre">on_delete</span></tt></a>
documentation.</p>
</div>
<div class="section" id="s-contextual-markers-in-translatable-strings">
<span id="contextual-markers-in-translatable-strings"></span><h3>Contextual markers in translatable strings<a class="headerlink" href="#contextual-markers-in-translatable-strings" title="Permalink to this headline">¶</a></h3>
<p>For translation strings with ambiguous meaning, you can now
use the <tt class="docutils literal"><span class="pre">pgettext</span></tt> function to specify the context of the string.</p>
<p>For more information, see <a class="reference internal" href="../topics/i18n/translation.html#contextual-markers"><em>Contextual markers</em></a></p>
</div>
<div class="section" id="s-everything-else">
<span id="everything-else"></span><h3>Everything else<a class="headerlink" href="#everything-else" title="Permalink to this headline">¶</a></h3>
<p>Django <a class="reference internal" href="1.1.html"><em>1.1</em></a> and <a class="reference internal" href="1.2.html"><em>1.2</em></a> added
lots of big ticket items to Django, like multiple-database support,
model validation, and a session-based messages framework. However,
this focus on big features came at the cost of lots of smaller
features.</p>
<p>To compensate for this, the focus of the Django 1.3 development
process has been on adding lots of smaller, long standing feature
requests. These include:</p>
<ul class="simple">
<li>Improved tools for accessing and manipulating the current Site via
<tt class="docutils literal"><span class="pre">django.contrib.sites.models.get_current_site()</span></tt>.</li>
<li>A <a class="reference internal" href="../topics/testing/advanced.html#django.test.client.RequestFactory" title="django.test.client.RequestFactory"><tt class="xref py py-class docutils literal"><span class="pre">RequestFactory</span></tt></a> for mocking
requests in tests.</li>
<li>A new test assertion –
<a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase.assertNumQueries" title="django.test.TransactionTestCase.assertNumQueries"><tt class="xref py py-meth docutils literal"><span class="pre">assertNumQueries()</span></tt></a> – making it
easier to test the database activity associated with a view.</li>
</ul>
</div>
</div>
<div class="section" id="s-backwards-incompatible-changes-in-1-3-alpha-1">
<span id="s-backwards-incompatible-changes-1-3-alpha-1"></span><span id="backwards-incompatible-changes-in-1-3-alpha-1"></span><span id="backwards-incompatible-changes-1-3-alpha-1"></span><h2>Backwards-incompatible changes in 1.3 alpha 1<a class="headerlink" href="#backwards-incompatible-changes-in-1-3-alpha-1" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-passwordinput-default-rendering-behavior">
<span id="passwordinput-default-rendering-behavior"></span><h3>PasswordInput default rendering behavior<a class="headerlink" href="#passwordinput-default-rendering-behavior" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/forms/widgets.html#django.forms.PasswordInput" title="django.forms.PasswordInput"><tt class="xref py py-class docutils literal"><span class="pre">PasswordInput</span></tt></a> form widget, intended for use
with form fields which represent passwords, accepts a boolean keyword
argument <tt class="docutils literal"><span class="pre">render_value</span></tt> indicating whether to send its data back to
the browser when displaying a submitted form with errors. Prior to
Django 1.3, this argument defaulted to <tt class="docutils literal"><span class="pre">True</span></tt>, meaning that the
submitted password would be sent back to the browser as part of the
form. Developers who wished to add a bit of additional security by
excluding that value from the redisplayed form could instantiate a
<a class="reference internal" href="../ref/forms/widgets.html#django.forms.PasswordInput" title="django.forms.PasswordInput"><tt class="xref py py-class docutils literal"><span class="pre">PasswordInput</span></tt></a> passing <tt class="docutils literal"><span class="pre">render_value=False</span></tt> .</p>
<p>Due to the sensitive nature of passwords, however, Django 1.3 takes
this step automatically; the default value of <tt class="docutils literal"><span class="pre">render_value</span></tt> is now
<tt class="docutils literal"><span class="pre">False</span></tt>, and developers who want the password value returned to the
browser on a submission with errors (the previous behavior) must now
explicitly indicate this. For example:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">LoginForm</span><span class="p">(</span><span class="n">forms</span><span class="o">.</span><span class="n">Form</span><span class="p">):</span>
<span class="n">username</span> <span class="o">=</span> <span class="n">forms</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">100</span><span class="p">)</span>
<span class="n">password</span> <span class="o">=</span> <span class="n">forms</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">widget</span><span class="o">=</span><span class="n">forms</span><span class="o">.</span><span class="n">PasswordInput</span><span class="p">(</span><span class="n">render_value</span><span class="o">=</span><span class="bp">True</span><span class="p">))</span>
</pre></div>
</div>
</div>
<div class="section" id="s-clearable-default-widget-for-filefield">
<span id="clearable-default-widget-for-filefield"></span><h3>Clearable default widget for FileField<a class="headerlink" href="#clearable-default-widget-for-filefield" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 now includes a <tt class="docutils literal"><span class="pre">ClearableFileInput</span></tt> form widget in addition to
<tt class="docutils literal"><span class="pre">FileInput</span></tt>. <tt class="docutils literal"><span class="pre">ClearableFileInput</span></tt> renders with a checkbox to clear the
field’s value (if the field has a value and is not required); <tt class="docutils literal"><span class="pre">FileInput</span></tt>
provided no means for clearing an existing file from a <tt class="docutils literal"><span class="pre">FileField</span></tt>.</p>
<p><tt class="docutils literal"><span class="pre">ClearableFileInput</span></tt> is now the default widget for a <tt class="docutils literal"><span class="pre">FileField</span></tt>, so
existing forms including <tt class="docutils literal"><span class="pre">FileField</span></tt> without assigning a custom widget will
need to account for the possible extra checkbox in the rendered form output.</p>
<p>To return to the previous rendering (without the ability to clear the
<tt class="docutils literal"><span class="pre">FileField</span></tt>), use the <tt class="docutils literal"><span class="pre">FileInput</span></tt> widget in place of
<tt class="docutils literal"><span class="pre">ClearableFileInput</span></tt>. For instance, in a <tt class="docutils literal"><span class="pre">ModelForm</span></tt> for a hypothetical
<tt class="docutils literal"><span class="pre">Document</span></tt> model with a <tt class="docutils literal"><span class="pre">FileField</span></tt> named <tt class="docutils literal"><span class="pre">document</span></tt>:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django</span> <span class="kn">import</span> <span class="n">forms</span>
<span class="kn">from</span> <span class="nn">myapp.models</span> <span class="kn">import</span> <span class="n">Document</span>
<span class="k">class</span> <span class="nc">DocumentForm</span><span class="p">(</span><span class="n">forms</span><span class="o">.</span><span class="n">ModelForm</span><span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">model</span> <span class="o">=</span> <span class="n">Document</span>
<span class="n">widgets</span> <span class="o">=</span> <span class="p">{</span><span class="s">'document'</span><span class="p">:</span> <span class="n">forms</span><span class="o">.</span><span class="n">FileInput</span><span class="p">}</span>
</pre></div>
</div>
</div>
<div class="section" id="s-new-index-on-database-session-table">
<span id="new-index-on-database-session-table"></span><h3>New index on database session table<a class="headerlink" href="#new-index-on-database-session-table" title="Permalink to this headline">¶</a></h3>
<p>Prior to Django 1.3, the database table used by the database backend
for the <a class="reference internal" href="../topics/http/sessions.html"><em>sessions</em></a> app had no index on
the <tt class="docutils literal"><span class="pre">expire_date</span></tt> column. As a result, date-based queries on the
session table – such as the query that is needed to purge old
sessions – would be very slow if there were lots of sessions.</p>
<p>If you have an existing project that is using the database session
backend, you don’t have to do anything to accommodate this change.
However, you may get a significant performance boost if you manually
add the new index to the session table. The SQL that will add the
index can be found by running the <a class="reference internal" href="../ref/django-admin.html#django-admin-sqlindexes"><tt class="xref std std-djadmin docutils literal"><span class="pre">sqlindexes</span></tt></a> admin
command:</p>
<div class="highlight-python"><pre>python manage.py sqlindexes sessions</pre>
</div>
</div>
<div class="section" id="s-no-more-naughty-words">
<span id="no-more-naughty-words"></span><h3>No more naughty words<a class="headerlink" href="#no-more-naughty-words" title="Permalink to this headline">¶</a></h3>
<p>Django has historically provided (and enforced) a list of profanities.
The <a class="reference internal" href="../ref/contrib/comments/index.html"><em>comments app</em></a> has enforced this
list of profanities, preventing people from submitting comments that
contained one of those profanities.</p>
<p>Unfortunately, the technique used to implement this profanities list
was woefully naive, and prone to the <a class="reference external" href="http://en.wikipedia.org/wiki/Scunthorpe_problem">Scunthorpe problem</a>. Fixing the
built in filter to fix this problem would require significant effort,
and since natural language processing isn’t the normal domain of a web
framework, we have “fixed” the problem by making the list of
prohibited words an empty list.</p>
<p>If you want to restore the old behavior, simply put a
<a class="reference internal" href="../ref/settings.html#std:setting-PROFANITIES_LIST"><tt class="xref std std-setting docutils literal"><span class="pre">PROFANITIES_LIST</span></tt></a> setting in your settings file that includes the
words that you want to prohibit (see the <a class="reference external" href="https://code.djangoproject.com/changeset/13996">commit that implemented this
change</a> if you want to see the list of words that was historically
prohibited). However, if avoiding profanities is important to you, you
would be well advised to seek out a better, less naive approach to the
problem.</p>
</div>
<div class="section" id="s-localflavor-changes">
<span id="localflavor-changes"></span><h3>Localflavor changes<a class="headerlink" href="#localflavor-changes" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 introduces the following backwards-incompatible changes to
local flavors:</p>
<ul class="simple">
<li>Indonesia (id) – The province “Nanggroe Aceh Darussalam (NAD)”
has been removed from the province list in favor of the new
official designation “Aceh (ACE)”.</li>
</ul>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-3">
<span id="features-deprecated-in-1-3"></span><h2>Features deprecated in 1.3<a class="headerlink" href="#features-deprecated-in-1-3" title="Permalink to this headline">¶</a></h2>
<p>Django 1.3 deprecates some features from earlier releases.
These features are still supported, but will be gradually phased out
over the next few release cycles.</p>
<p>Code taking advantage of any of the features below will raise a
<tt class="docutils literal"><span class="pre">PendingDeprecationWarning</span></tt> in Django 1.3. This warning will be
silent by default, but may be turned on using Python’s <tt class="xref py py-mod docutils literal"><span class="pre">warnings</span></tt>
module, or by running Python with a <tt class="docutils literal"><span class="pre">-Wd</span></tt> or <tt class="docutils literal"><span class="pre">-Wall</span></tt> flag.</p>
<p>In Django 1.4, these warnings will become a <tt class="docutils literal"><span class="pre">DeprecationWarning</span></tt>,
which is <em>not</em> silent. In Django 1.5 support for these features will
be removed entirely.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">For more details, see the documentation <a class="reference internal" href="../internals/release-process.html"><em>Django’s release process</em></a> and our <a class="reference internal" href="../internals/deprecation.html"><em>deprecation timeline</em></a>.</p>
</div>
<div class="section" id="s-mod-python-support">
<span id="mod-python-support"></span><h3><tt class="docutils literal"><span class="pre">mod_python</span></tt> support<a class="headerlink" href="#mod-python-support" title="Permalink to this headline">¶</a></h3>
<p>The <tt class="docutils literal"><span class="pre">mod_python</span></tt> library has not had a release since 2007 or a commit since
2008. The Apache Foundation board voted to remove <tt class="docutils literal"><span class="pre">mod_python</span></tt> from the set
of active projects in its version control repositories, and its lead developer
has shifted all of his efforts toward the lighter, slimmer, more stable, and
more flexible <tt class="docutils literal"><span class="pre">mod_wsgi</span></tt> backend.</p>
<p>If you are currently using the <tt class="docutils literal"><span class="pre">mod_python</span></tt> request handler, you are strongly
encouraged to redeploy your Django instances using <a class="reference internal" href="../howto/deployment/wsgi/modwsgi.html"><em>mod_wsgi</em></a>.</p>
</div>
<div class="section" id="s-function-based-generic-views">
<span id="function-based-generic-views"></span><h3>Function-based generic views<a class="headerlink" href="#function-based-generic-views" title="Permalink to this headline">¶</a></h3>
<p>As a result of the introduction of class-based generic views, the
function-based generic views provided by Django have been deprecated.
The following modules and the views they contain have been deprecated:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">django.views.generic.create_update</span></tt></li>
<li><tt class="docutils literal"><span class="pre">django.views.generic.date_based</span></tt></li>
<li><tt class="docutils literal"><span class="pre">django.views.generic.list_detail</span></tt></li>
<li><tt class="docutils literal"><span class="pre">django.views.generic.simple</span></tt></li>
</ul>
</div>
<div class="section" id="s-test-client-response-template-attribute">
<span id="test-client-response-template-attribute"></span><h3>Test client response <tt class="docutils literal"><span class="pre">template</span></tt> attribute<a class="headerlink" href="#test-client-response-template-attribute" title="Permalink to this headline">¶</a></h3>
<p>Django’s <a class="reference internal" href="../topics/testing/tools.html#test-client"><em>test client</em></a> returns
<a class="reference internal" href="../topics/testing/tools.html#django.test.client.Response" title="django.test.client.Response"><tt class="xref py py-class docutils literal"><span class="pre">Response</span></tt></a> objects annotated with extra testing
information. In Django versions prior to 1.3, this included a <tt class="docutils literal"><span class="pre">template</span></tt>
attribute containing information about templates rendered in generating the
response: either None, a single <a class="reference internal" href="../ref/templates/api.html#django.template.Template" title="django.template.Template"><tt class="xref py py-class docutils literal"><span class="pre">Template</span></tt></a> object, or a
list of <a class="reference internal" href="../ref/templates/api.html#django.template.Template" title="django.template.Template"><tt class="xref py py-class docutils literal"><span class="pre">Template</span></tt></a> objects. This inconsistency in
return values (sometimes a list, sometimes not) made the attribute difficult
to work with.</p>
<p>In Django 1.3 the <tt class="docutils literal"><span class="pre">template</span></tt> attribute is deprecated in favor of a new
<a class="reference internal" href="../topics/testing/tools.html#django.test.client.Response.templates" title="django.test.client.Response.templates"><tt class="xref py py-attr docutils literal"><span class="pre">templates</span></tt></a> attribute, which is always a
list, even if it has only a single element or no elements.</p>
</div>
<div class="section" id="s-djangotestrunner">
<span id="djangotestrunner"></span><h3><tt class="docutils literal"><span class="pre">DjangoTestRunner</span></tt><a class="headerlink" href="#djangotestrunner" title="Permalink to this headline">¶</a></h3>
<p>As a result of the introduction of support for unittest2, the features
of <tt class="docutils literal"><span class="pre">django.test.simple.DjangoTestRunner</span></tt> (including fail-fast
and Ctrl-C test termination) have been made redundant. In view of this
redundancy, <tt class="docutils literal"><span class="pre">DjangoTestRunner</span></tt> has been turned into an empty placeholder
class, and will be removed entirely in Django 1.5.</p>
</div>
</div>
<div class="section" id="s-the-django-1-3-roadmap">
<span id="the-django-1-3-roadmap"></span><h2>The Django 1.3 roadmap<a class="headerlink" href="#the-django-1-3-roadmap" title="Permalink to this headline">¶</a></h2>
<p>Before the final Django 1.3 release, several other preview/development
releases will be made available. The current schedule consists of at
least the following:</p>
<ul class="simple">
<li>Week of <strong>November 29, 2010</strong>: First Django 1.3 beta release. Final
feature freeze for Django 1.3.</li>
<li>Week of <strong>January 10, 2011</strong>: First Django 1.3 release
candidate. String freeze for translations.</li>
<li>Week of <strong>January 17, 2011</strong>: Django 1.3 final release.</li>
</ul>
<p>If necessary, additional alpha, beta or release-candidate packages
will be issued prior to the final 1.3 release. Django 1.3 will be
released approximately one week after the final release candidate.</p>
</div>
<div class="section" id="s-what-you-can-do-to-help">
<span id="what-you-can-do-to-help"></span><h2>What you can do to help<a class="headerlink" href="#what-you-can-do-to-help" title="Permalink to this headline">¶</a></h2>
<p>In order to provide a high-quality 1.3 release, we need your help. Although this
alpha release is, again, <em>not</em> intended for production use, you can help the
Django team by trying out the alpha codebase in a safe test environment and
reporting any bugs or issues you encounter. The Django ticket tracker is the
central place to search for open issues:</p>
<ul class="simple">
<li><a class="reference external" href="https://code.djangoproject.com/timeline">https://code.djangoproject.com/timeline</a></li>
</ul>
<p>Please open new tickets if no existing ticket corresponds to a problem you’re
running into.</p>
<p>Additionally, discussion of Django development, including progress toward the
1.3 release, takes place daily on the django-developers mailing list:</p>
<ul class="simple">
<li><a class="reference external" href="http://groups.google.com/group/django-developers">http://groups.google.com/group/django-developers</a></li>
</ul>
<p>... and in the <tt class="docutils literal"><span class="pre">#django-dev</span></tt> IRC channel on <tt class="docutils literal"><span class="pre">irc.freenode.net</span></tt>. If you’re
interested in helping out with Django’s development, feel free to join the
discussions there.</p>
<p>Django’s online documentation also includes pointers on how to contribute to
Django:</p>
<ul class="simple">
<li><a class="reference internal" href="../internals/contributing/index.html"><em>How to contribute to Django</em></a></li>
</ul>
<p>Contributions on any level – developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes – are always welcome and
appreciated.</p>
<p>Several development sprints will also be taking place before the 1.3
release; these will typically be announced in advance on the
django-developers mailing list, and anyone who wants to help is
welcome to join in.</p>
</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.3 alpha 1 release notes</a><ul>
<li><a class="reference internal" href="#what-s-new-in-django-1-3-alpha-1">What’s new in Django 1.3 alpha 1</a><ul>
<li><a class="reference internal" href="#class-based-views">Class-based views</a></li>
<li><a class="reference internal" href="#logging">Logging</a></li>
<li><a class="reference internal" href="#extended-static-files-handling">Extended static files handling</a></li>
<li><a class="reference internal" href="#unittest2-support"><tt class="docutils literal"><span class="pre">unittest2</span></tt> support</a></li>
<li><a class="reference internal" href="#transaction-context-managers">Transaction context managers</a></li>
<li><a class="reference internal" href="#configurable-delete-cascade">Configurable delete-cascade</a></li>
<li><a class="reference internal" href="#contextual-markers-in-translatable-strings">Contextual markers in translatable strings</a></li>
<li><a class="reference internal" href="#everything-else">Everything else</a></li>
</ul>
</li>
<li><a class="reference internal" href="#backwards-incompatible-changes-in-1-3-alpha-1">Backwards-incompatible changes in 1.3 alpha 1</a><ul>
<li><a class="reference internal" href="#passwordinput-default-rendering-behavior">PasswordInput default rendering behavior</a></li>
<li><a class="reference internal" href="#clearable-default-widget-for-filefield">Clearable default widget for FileField</a></li>
<li><a class="reference internal" href="#new-index-on-database-session-table">New index on database session table</a></li>
<li><a class="reference internal" href="#no-more-naughty-words">No more naughty words</a></li>
<li><a class="reference internal" href="#localflavor-changes">Localflavor changes</a></li>
</ul>
</li>
<li><a class="reference internal" href="#features-deprecated-in-1-3">Features deprecated in 1.3</a><ul>
<li><a class="reference internal" href="#mod-python-support"><tt class="docutils literal"><span class="pre">mod_python</span></tt> support</a></li>
<li><a class="reference internal" href="#function-based-generic-views">Function-based generic views</a></li>
<li><a class="reference internal" href="#test-client-response-template-attribute">Test client response <tt class="docutils literal"><span class="pre">template</span></tt> attribute</a></li>
<li><a class="reference internal" href="#djangotestrunner"><tt class="docutils literal"><span class="pre">DjangoTestRunner</span></tt></a></li>
</ul>
</li>
<li><a class="reference internal" href="#the-django-1-3-roadmap">The Django 1.3 roadmap</a></li>
<li><a class="reference internal" href="#what-you-can-do-to-help">What you can do to help</a></li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="1.3-beta-1.html">Django 1.3 beta 1 release notes</a></li>
<li>Next: <a href="1.2-rc-1.html">Django 1.2 RC 1 release notes</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django 1.6.7 documentation</a>
<ul><li><a href="index.html">Release notes</a>
<ul><li>Django 1.3 alpha 1 release notes</li></ul>
</li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/releases/1.3-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">Sep 26, 2014</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="1.3-beta-1.html" title="Django 1.3 beta 1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.2-rc-1.html" title="Django 1.2 RC 1 release notes">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
