-
-
Notifications
You must be signed in to change notification settings - Fork 31.6k
/
1.3-alpha-1.txt
402 lines (296 loc) · 15.8 KB
/
1.3-alpha-1.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
================================
Django 1.3 alpha 1 release notes
================================
November 11, 2010
Welcome to Django 1.3 alpha 1!
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.
As such, this release is *not* intended for production use, and any such use is
discouraged.
As of this alpha release, Django 1.3 contains a number of nifty `new
features`_, lots of bug fixes, some minor `backwards incompatible
changes`_ and an easy upgrade path from Django 1.2.
.. _new features: `What's new in Django 1.3 alpha 1`_
.. _backwards incompatible changes: backwards-incompatible-changes-1.3-alpha-1_
What's new in Django 1.3 alpha 1
================================
Class-based views
~~~~~~~~~~~~~~~~~
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.
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.
See :doc:`the documentation on Class-based Generic Views
</topics/class-based-views>` for more details. There is also a document to
help you :doc:`convert your function-based generic views to class-based
views</topics/generic-views-migration>`.
Logging
~~~~~~~
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 :doc:`the documentation on Django's logging
interface </topics/logging>` for more details.
Extended static files handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.3 ships with a new contrib app ``'django.contrib.staticfiles'``
to help developers handle the static media files (images, CSS, Javascript,
etc.) that are needed to render a complete web page.
In previous versions of Django, it was common to place static assets in
:setting:`MEDIA_ROOT` along with user-uploaded files, and serve them both at
:setting:`MEDIA_URL`. Part of the purpose of introducing the ``staticfiles``
app is to make it easier to keep static files separate from user-uploaded
files. For this reason, you will probably want to make your
:setting:`MEDIA_ROOT` and :setting:`MEDIA_URL` different from your
:setting:`STATICFILES_ROOT` and :setting:`STATICFILES_URL`. You will need to
arrange for serving of files in :setting:`MEDIA_ROOT` yourself;
``staticfiles`` does not deal with user-uploaded media at all.
See the :doc:`reference documentation of the app </ref/contrib/staticfiles>`
for more details or learn how to :doc:`manage static files
</howto/static-files>`.
``unittest2`` support
~~~~~~~~~~~~~~~~~~~~~
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 unittest2_, a copy of the Python 2.7 unittest library,
backported for Python 2.4 compatibility.
To access this library, Django provides the
``django.utils.unittest`` 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 it's own bundled version of unittest2.
To use this alias, simply use::
from django.utils import unittest
wherever you would have historically used::
import unittest
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.
.. _unittest2: http://pypi.python.org/pypi/unittest2
Transaction context managers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Users of Python 2.5 and above may now use :ref:`transaction management functions
<transaction-management-functions>` as `context managers`_. For example::
with transaction.autocommit():
# ...
.. _context managers: http://docs.python.org/glossary.html#term-context-manager
For more information, see :ref:`transaction-management-functions`.
Configurable delete-cascade
~~~~~~~~~~~~~~~~~~~~~~~~~~~
:class:`~django.db.models.ForeignKey` and
:class:`~django.db.models.OneToOneField` now accept an
:attr:`~django.db.models.ForeignKey.on_delete` 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.
For more information, see the :attr:`~django.db.models.ForeignKey.on_delete`
documentation.
Contextual markers in translatable strings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For translation strings with ambiguous meaning, you can now
use the ``pgettext`` function to specify the context of the string.
For more information, see :ref:`contextual-markers`
Everything else
~~~~~~~~~~~~~~~
Django :doc:`1.1 <1.1>` and :doc:`1.2 <1.2>` 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.
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:
* Improved tools for accessing and manipulating the current Site via
:func:`django.contrib.sites.models.get_current_site`.
* A :class:`~django.test.client.RequestFactory` for mocking
requests in tests.
* A new test assertion --
:meth:`~django.test.client.Client.assertNumQueries` -- making it
easier to test the database activity associated with a view.
.. _backwards-incompatible-changes-1.3-alpha-1:
Backwards-incompatible changes in 1.3 alpha 1
=============================================
PasswordInput default rendering behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The :class:`~django.forms.PasswordInput` form widget, intended for use
with form fields which represent passwords, accepts a boolean keyword
argument ``render_value`` 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 ``True``, 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
:class:`~django.forms.PasswordInput` passing ``render_value=False`` .
Due to the sensitive nature of passwords, however, Django 1.3 takes
this step automatically; the default value of ``render_value`` is now
``False``, 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::
class LoginForm(forms.Form):
username = forms.CharField(max_length=100)
password = forms.CharField(widget=forms.PasswordInput(render_value=True))
Clearable default widget for FileField
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django 1.3 now includes a ``ClearableFileInput`` form widget in addition to
``FileInput``. ``ClearableFileInput`` renders with a checkbox to clear the
field's value (if the field has a value and is not required); ``FileInput``
provided no means for clearing an existing file from a ``FileField``.
``ClearableFileInput`` is now the default widget for a ``FileField``, so
existing forms including ``FileField`` without assigning a custom widget will
need to account for the possible extra checkbox in the rendered form output.
To return to the previous rendering (without the ability to clear the
``FileField``), use the ``FileInput`` widget in place of
``ClearableFileInput``. For instance, in a ``ModelForm`` for a hypothetical
``Document`` model with a ``FileField`` named ``document``::
from django import forms
from myapp.models import Document
class DocumentForm(forms.ModelForm):
class Meta:
model = Document
widgets = {'document': forms.FileInput}
New index on database session table
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prior to Django 1.3, the database table used by the database backend
for the :doc:`sessions </topics/http/sessions>` app had no index on
the ``expire_date`` 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.
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 :djadmin:`sqlindexes` admin
command::
python manage.py sqlindexes sessions
No more naughty words
~~~~~~~~~~~~~~~~~~~~~
Django has historically provided (and enforced) a list of profanities.
The :doc:`comments app </ref/contrib/comments/index>` has enforced this
list of profanities, preventing people from submitting comments that
contained one of those profanities.
Unfortunately, the technique used to implement this profanities list
was woefully naive, and prone to the `Scunthorpe problem`_. 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.
If you want to restore the old behavior, simply put a
:setting:`PROFANITIES_LIST` setting in your settings file that includes the
words that you want to prohibit (see the `commit that implemented this
change`_ 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.
.. _Scunthorpe problem: http://en.wikipedia.org/wiki/Scunthorpe_problem
.. _commit that implemented this change: http://code.djangoproject.com/changeset/13996
Localflavor changes
~~~~~~~~~~~~~~~~~~~
Django 1.3 introduces the following backwards-incompatible changes to
local flavors:
* Indonesia (id) -- The province "Nanggroe Aceh Darussalam (NAD)"
has been removed from the province list in favor of the new
official designation "Aceh (ACE)".
Features deprecated in 1.3
==========================
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.
Code taking advantage of any of the features below will raise a
``PendingDeprecationWarning`` in Django 1.3. This warning will be
silent by default, but may be turned on using Python's :mod:`warnings`
module, or by running Python with a ``-Wd`` or `-Wall` flag.
In Django 1.4, these warnings will become a ``DeprecationWarning``,
which is *not* silent. In Django 1.5 support for these features will
be removed entirely.
.. seealso::
For more details, see the documentation :doc:`Django's release process
</internals/release-process>` and our :doc:`deprecation timeline
</internals/deprecation>`.
``mod_python`` support
~~~~~~~~~~~~~~~~~~~~~~
The ``mod_python`` library has not had a release since 2007 or a commit since
2008. The Apache Foundation board voted to remove ``mod_python`` 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 ``mod_wsgi`` backend.
If you are currently using the ``mod_python`` request handler, you are strongly
encouraged to redeploy your Django instances using :doc:`mod_wsgi
</howto/deployment/wsgi/modwsgi>`.
Function-based generic views
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:
* :mod:`django.views.generic.create_update`
* :mod:`django.views.generic.date_based`
* :mod:`django.views.generic.list_detail`
* :mod:`django.views.generic.simple`
Test client response ``template`` attribute
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Django's :ref:`test client <test-client>` returns
:class:`~django.test.client.Response` objects annotated with extra testing
information. In Django versions prior to 1.3, this included a
:attr:`~django.test.client.Response.template` attribute containing information
about templates rendered in generating the response: either None, a single
:class:`~django.template.Template` object, or a list of
:class:`~django.template.Template` objects. This inconsistency in return values
(sometimes a list, sometimes not) made the attribute difficult to work with.
In Django 1.3 the :attr:`~django.test.client.Response.template` attribute is
deprecated in favor of a new :attr:`~django.test.client.Response.templates`
attribute, which is always a list, even if it has only a single element or no
elements.
``DjangoTestRunner``
~~~~~~~~~~~~~~~~~~~~
As a result of the introduction of support for unittest2, the features
of :class:`django.test.simple.DjangoTestRunner` (including fail-fast
and Ctrl-C test termination) have been made redundant. In view of this
redundancy, :class:`~django.test.simple.DjangoTestRunner` has been
turned into an empty placeholder class, and will be removed entirely
in Django 1.5.
The Django 1.3 roadmap
======================
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:
* Week of **November 29, 2010**: First Django 1.3 beta release. Final
feature freeze for Django 1.3.
* Week of **January 10, 2011**: First Django 1.3 release
candidate. String freeze for translations.
* Week of **January 17, 2011**: Django 1.3 final release.
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.
What you can do to help
=======================
In order to provide a high-quality 1.3 release, we need your help. Although this
alpha release is, again, *not* 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:
* http://code.djangoproject.com/timeline
Please open new tickets if no existing ticket corresponds to a problem you're
running into.
Additionally, discussion of Django development, including progress toward the
1.3 release, takes place daily on the django-developers mailing list:
* http://groups.google.com/group/django-developers
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
interested in helping out with Django's development, feel free to join the
discussions there.
Django's online documentation also includes pointers on how to contribute to
Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.
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.