[Changeset] r13259 - django/trunk/docs/releases

[noreply]

Author: ubernostrum
Date: 2010-05-14 01:51:42 -0500 (Fri, 14 May 2010)
New Revision: 13259

Modified:
   django/trunk/docs/releases/1.2.txt
Log:
Update 1.2 release notes in anticipation of final release.

Modified: django/trunk/docs/releases/1.2.txt
===
--- django/trunk/docs/releases/1.2.txt  2010-05-14 06:00:30 UTC (rev 13258)
+++ django/trunk/docs/releases/1.2.txt  2010-05-14 06:51:42 UTC (rev 13259)
@@ -1,16 +1,19 @@
 .. _releases-1.2:
 
-
-Django 1.2 release notes — UNDER DEVELOPMENT
-
+
+Django 1.2 release notes
+
 
-This page documents release notes for the as-yet-unreleased Django 1.2. As 
such,
-it's tentative and subject to change. It provides up-to-date information for
-those who are following trunk.
 
-Django 1.2 includes a number of nifty `new features`_, lots of bug
-fixes and an easy upgrade path from Django 1.1.
+May 14, 2010
 
+Welcome to Django 1.2!
+
+Nearly a year in the making, Django 1.2 packs an impressive list of
+`new features`_, and lots of bugfixes. These release notes cover the
+new features, as well as important changes you'll want to be aware of
+when upgrading from Djagno 1.1 or older versions.
+
 .. _new features: `What's new in Django 1.2`_
 
 .. _backwards-incompatible-changes-1.2:
@@ -18,6 +21,19 @@
 Backwards-incompatible changes in 1.2
 =
 
+There are a number of changes in Django 1.2 which will be
+backwards-incompatible; per :ref:`our API stability policy
+`, most such changes are being introduced
+gradually to allow adequate time to upgrade existing code. For most of
+the changes listed below, code written for Django 1.1 or older will
+simply raise a ``PendingDeprecationWarning`` in Django 1.2, followed
+by a ``DeprecationWarning`` in Django 1.3 before such code finally
+stops working entirely in Django 1.4.
+
+Do note, however, that some of the items listed below may require
+immediate changes; we encourage you to read these notes carefully to
+determine how they'll impact your code.
+
 CSRF Protection
 ---
 
@@ -30,7 +46,7 @@
should be inserted into forms.
 
  * All contrib apps use a ``csrf_protect`` decorator to protect the view. This
-   requires the use of the csrf_token template tag in the template. If you
+   requires the use of the ``csrf_token`` template tag in the template. If you
have used custom templates for contrib views, you MUST READ THE 
:ref:`UPGRADE
INSTRUCTIONS ` to fix those templates.
 
@@ -39,8 +55,9 @@
POST requests need to be written to work with the middleware. Instructions
on how to do this are found in the CSRF docs.
 
- * All of the CSRF has moved from contrib to core (with backwards compatible
-   imports in the old locations, which are deprecated).
+ * All of the CSRF has moved from contrib to core (with backwards
+   compatible imports in the old locations, which are deprecated and
+   will cease to be supported in Django 1.4).
 
 :ttag:`if` tag changes
 --
@@ -50,19 +67,21 @@
 cases even though these strings were normally treated as keywords. Now, the
 keyword status is always enforced, and template code such as ``{% if not %}`` 
or
 ``{% if and %}`` will throw a ``TemplateSyntaxError``. Also, ``in`` is a new
-keyword and so is not a valid variable name in this context.
+keyword and so is not a valid variable name in this tag.
 
 ``LazyObject``
 --
 
-``LazyObject`` is an undocumented utility class used for lazily wrapping other
-objects of unknown type. In Django 1.1 and earlier, it handled introspection in
-a non-standard way, depending on wrapped objects implementing a public method
-``get_all_members()``. Since this could easily lead to name clashes, it has 
been
-changed to use the standard method, involving ``__members__`` and 
``__dir__()``.
-If you used ``LazyObject`` in your own code and implemented the
-``get_all_members()`` method for wrapped objects, you need to make the 
following
-changes:
+``LazyObject`` is an undocumented utility class used for lazily
+wrapping other objects of unknown type. In Django 1.1 and earlier, it
+handled introspection in a non-standard way, depending on wrapped
+objects implementing a public method named
+``get_all_members()``. Since this could easily lead to name clashes,
+it has been changed to use the standard Python introspection method,
+involving ``__members__`` and ``__dir__()``.  If you used
+``LazyObject`` in your own code and implemented the
+``get_all_members()`` method for wrapped objects, you need to make the
+following changes:
 
  * If your class does not have special requirements for introspection (i.e., 
you
have not implemented ``__getattr__()`` or other methods that allow for
@@ -70,39 +89,41 @@
``get_all_members()`` method. The default implementation on ``LazyObject``
   

[Django] #13535: E-mail date header should be in the local time zone

[Django]

#13535: E-mail date header should be in the local time zone
--+-
 Reporter:  geofft|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.core.mail  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Outgoing e-mails should use the time zone of the application instead of
 hardcoding UTC-0. In addition to generally making more sense for servers
 outside England, my e-mail client (alpine) happens to display the time in
 the index view without converting it to local time. Fortunately, using the
 local time zone is easy:

 {{{
 >>> email.Utils.formatdate()
 'Fri, 14 May 2010 06:38:42 -'
 >>> email.Utils.formatdate(localtime=True)
 'Fri, 14 May 2010 02:39:33 -0400'
 }}}

 I've attached a patch to django.core.mail.message to effect this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r13258 - django/tags/releases

[noreply]

Author: ubernostrum
Date: 2010-05-14 01:00:30 -0500 (Fri, 14 May 2010)
New Revision: 13258

Added:
   django/tags/releases/1.1.2/
Log:
Tag 1.1.2

Copied: django/tags/releases/1.1.2 (from rev 13256, 
django/branches/releases/1.1.X)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r13257 - in django/branches/releases/1.1.X: . django

[noreply]

Author: ubernostrum
Date: 2010-05-14 00:56:34 -0500 (Fri, 14 May 2010)
New Revision: 13257

Modified:
   django/branches/releases/1.1.X/django/__init__.py
   django/branches/releases/1.1.X/setup.py
Log:
[1.1.X] This branch is now 1.1.3 pre-alpha.

Modified: django/branches/releases/1.1.X/django/__init__.py
===
--- django/branches/releases/1.1.X/django/__init__.py   2010-05-14 05:45:12 UTC 
(rev 13256)
+++ django/branches/releases/1.1.X/django/__init__.py   2010-05-14 05:56:34 UTC 
(rev 13257)
@@ -1,4 +1,4 @@
-VERSION = (1, 1, 2, 'final', 0)
+VERSION = (1, 1, 3, 'alpha', 0)
 
 def get_version():
 version = '%s.%s' % (VERSION[0], VERSION[1])

Modified: django/branches/releases/1.1.X/setup.py
===
--- django/branches/releases/1.1.X/setup.py 2010-05-14 05:45:12 UTC (rev 
13256)
+++ django/branches/releases/1.1.X/setup.py 2010-05-14 05:56:34 UTC (rev 
13257)
@@ -77,7 +77,6 @@
 author = 'Django Software Foundation',
 author_email = 'foundat...@djangoproject.com',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',
-download_url = 
'http://media.djangoproject.com/releases/1.1/Django-1.1.2.tar.gz',
 packages = packages,
 cmdclass = cmdclasses,
 data_files = data_files,

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r13256 - in django/branches/releases/1.1.X: . django

[noreply]

Author: ubernostrum
Date: 2010-05-14 00:45:12 -0500 (Fri, 14 May 2010)
New Revision: 13256

Modified:
   django/branches/releases/1.1.X/django/__init__.py
   django/branches/releases/1.1.X/setup.py
Log:
[1.1.X] Bump to 1.1.2.

Modified: django/branches/releases/1.1.X/django/__init__.py
===
--- django/branches/releases/1.1.X/django/__init__.py   2010-05-14 01:52:28 UTC 
(rev 13255)
+++ django/branches/releases/1.1.X/django/__init__.py   2010-05-14 05:45:12 UTC 
(rev 13256)
@@ -1,4 +1,4 @@
-VERSION = (1, 1, 2, 'alpha', 0)
+VERSION = (1, 1, 2, 'final', 0)
 
 def get_version():
 version = '%s.%s' % (VERSION[0], VERSION[1])

Modified: django/branches/releases/1.1.X/setup.py
===
--- django/branches/releases/1.1.X/setup.py 2010-05-14 01:52:28 UTC (rev 
13255)
+++ django/branches/releases/1.1.X/setup.py 2010-05-14 05:45:12 UTC (rev 
13256)
@@ -77,6 +77,7 @@
 author = 'Django Software Foundation',
 author_email = 'foundat...@djangoproject.com',
 description = 'A high-level Python Web framework that encourages rapid 
development and clean, pragmatic design.',
+download_url = 
'http://media.djangoproject.com/releases/1.1/Django-1.1.2.tar.gz',
 packages = packages,
 cmdclass = cmdclasses,
 data_files = data_files,

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13534: m2m_changed signal doesn't call receiver

[Django]

#13534: m2m_changed signal doesn't call receiver
---+
  Reporter:  Chris Targett   | Owner:  nobody 
   
Status:  closed| Milestone:  1.2
   
 Component:  Database layer (models, ORM)  |   Version:  
1.2-beta  
Resolution:  invalid   |  Keywords:  
m2m_save, dispatch, signal
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 The sample code is invalid on two counts:
  1) The relationship isn't a m2m, so of course it doesn't emit an m2m
 signal
  2) The sender of a m2m signal is bound to the through model, not the
 model defining the relationship. Assuming the key to Site was a m2m, you
 would need to connect:

 {{
 models.signals.m2m_changed.connect(m2m_handler, SomeContent.sites.through)
 }}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #13534: m2m_changed signal doesn't call receiver

[Django]

#13534: m2m_changed signal doesn't call receiver
--+-
 Reporter:  Chris Targett   |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Database layer (models, ORM)  | Version:  1.2-beta  
 Keywords:  m2m_save, dispatch, signal|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 For some reason or another the m2m_changed signal does not call the
 receiver.

 A rough models.py similar to my code:
 {{{
 #!python

 class SomeContent(models.Model):
   sites = models.ForeignKey(Site)

 def m2m_handler(sender, instance, action, reverse, model, pk_set,
 **kwargs):
   raise NotImplementedError
 models.signals.m2m_changed.connect(m2m_handler, SomeContent)


 >>> sc = SomeContent()
 >>> sc.save()
 >>> sc.sites.add(Site.objects.get_current()) # Here you would expect a
 "NotImplementedError"
 >>>
 }}}

 It seems the signal loses all receivers in
 `django.dispatch.dispatcher.Signal._line_receivers` line 215.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r13255 - django/branches/releases/1.1.X/docs/topics/db

[noreply]

Author: russellm
Date: 2010-05-13 20:52:28 -0500 (Thu, 13 May 2010)
New Revision: 13255

Modified:
   django/branches/releases/1.1.X/docs/topics/db/queries.txt
Log:
[1.1.X] Fixed #13532 -- Corrected and clarified examples in F() docs. Thanks to 
erw for the report and patch.

Backport of r13254 from trunk.

Modified: django/branches/releases/1.1.X/docs/topics/db/queries.txt
===
--- django/branches/releases/1.1.X/docs/topics/db/queries.txt   2010-05-14 
01:51:14 UTC (rev 13254)
+++ django/branches/releases/1.1.X/docs/topics/db/queries.txt   2010-05-14 
01:52:28 UTC (rev 13255)
@@ -512,17 +512,18 @@
 and use that ``F()`` object in the query::
 
 >>> from django.db.models import F
->>> Entry.objects.filter(n_pingbacks__lt=F('n_comments'))
+>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks'))
 
 Django supports the use of addition, subtraction, multiplication,
 division and modulo arithmetic with ``F()`` objects, both with constants
-and with other ``F()`` objects. To find all the blog entries with *twice* as
-many comments as pingbacks, we modify the query::
+and with other ``F()`` objects. To find all the blog entries with more than
+*twice* as many comments as pingbacks, we modify the query::
 
->>> Entry.objects.filter(n_pingbacks__lt=F('n_comments') * 2)
+>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)
 
-To find all the entries where the sum of the pingback count and comment count
-is greater than the rating of the entry, we would issue the query::
+To find all the entries where the rating of the entry is less than the
+sum of the pingback count and comment count, we would issue the
+query::
 
 >>> Entry.objects.filter(rating__lt=F('n_comments') + F('n_pingbacks'))
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r13254 - django/trunk/docs/topics/db

[noreply]

Author: russellm
Date: 2010-05-13 20:51:14 -0500 (Thu, 13 May 2010)
New Revision: 13254

Modified:
   django/trunk/docs/topics/db/queries.txt
Log:
Fixed #13532 -- Corrected and clarified examples in F() docs. Thanks to erw for 
the report and patch.

Modified: django/trunk/docs/topics/db/queries.txt
===
--- django/trunk/docs/topics/db/queries.txt 2010-05-13 13:44:32 UTC (rev 
13253)
+++ django/trunk/docs/topics/db/queries.txt 2010-05-14 01:51:14 UTC (rev 
13254)
@@ -512,17 +512,18 @@
 and use that ``F()`` object in the query::
 
 >>> from django.db.models import F
->>> Entry.objects.filter(n_pingbacks__lt=F('n_comments'))
+>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks'))
 
 Django supports the use of addition, subtraction, multiplication,
 division and modulo arithmetic with ``F()`` objects, both with constants
-and with other ``F()`` objects. To find all the blog entries with *twice* as
-many comments as pingbacks, we modify the query::
+and with other ``F()`` objects. To find all the blog entries with more than
+*twice* as many comments as pingbacks, we modify the query::
 
->>> Entry.objects.filter(n_pingbacks__lt=F('n_comments') * 2)
+>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)
 
-To find all the entries where the sum of the pingback count and comment count
-is greater than the rating of the entry, we would issue the query::
+To find all the entries where the rating of the entry is less than the
+sum of the pingback count and comment count, we would issue the
+query::
 
 >>> Entry.objects.filter(rating__lt=F('n_comments') + F('n_pingbacks'))
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13533: queries test fails under MySQL InnoDB

[Django]

#13533: queries test fails under MySQL InnoDB
---+
  Reporter:  russellm  | Owner:  nobody  
Status:  new   | Milestone:  1.3 
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #13533: queries test fails under MySQL InnoDB

[Django]

#13533: queries test fails under MySQL InnoDB
--+-
 Reporter:  russellm  |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  1.2-beta  
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 As of 1.2RC1, the queries test fails under MySQL InnoDB fails at the
 following test:
 {{{
 Failed example:
 Tag.objects.exclude(children=None)
 Expected:
 [, ]
 Got:
 [, , ]
 }}}

 This is at line 1150 (as of r13252).

 This test passes as is under SQLite, Postgres, and MySQL MyISAM.

 Even more weird - if you dig into the database at the time the test runs,
 the query is the same, and the contents of the table is the same. The
 issue appears to be entirely related to a query cache somewhere in the
 MySQLdb infrastructure, but only under InnoDB.

 You can make the test pass by inserting:
 {{{
 >>> connection.close()
 }}}

 just before the failing test. You can also make the test pass by manually
 issuing the same query twice, and only checking the test result on the
 second execution -- i.e., if you modify the test to the following:
 {{{
 >>> r = list(Tag.objects.exclude(children=None))
 >>> Tag.objects.exclude(children=None)
 [, ]
 }}}

 The test will pass.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13532: Error in F() object docs

[Django]

#13532: Error in F() object docs
+---
  Reporter:  erw| Owner:  erw
Status:  assigned   | Milestone:  1.2
 Component:  Documentation  |   Version: 
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by erw):

  * owner:  nobody => erw
  * status:  new => assigned
  * has_patch:  0 => 1

Comment:

 I think this patch fixes the problem and makes F() objects a bit easier to
 understand by using gt instead of lt.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6870: pre_delete should be sent before collecting ForeignKey relationships

[Django]

#6870: pre_delete should be sent before collecting ForeignKey relationships
-+--
  Reporter:  wkornewald  | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Core framework  |   Version:  SVN  
 
Resolution:  |  Keywords:  pre_delete 
signals related
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  1   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by cgieringer):

  * keywords:  => pre_delete signals related
  * needs_tests:  1 => 0

Comment:

 I added a test that deletes a model and asserts that another model with a
 foreign key to it had the opportunity to be rescued from deletion via a
 pre_delete signal

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13201: Broken link in 0.96 template docs

[Django]

#13201: Broken link in 0.96 template docs
-+--
  Reporter:  kcmarshall  | Owner:  andymckay
Status:  new | Milestone:   
 Component:  Django Web site |   Version:  0.96 
Resolution:  |  Keywords:  link 
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by jcd):

  * milestone:  1.2 =>

Comment:

 Not related to 1.2 in any way.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13532: Error in F() object docs

[Django]

#13532: Error in F() object docs
+---
  Reporter:  erw| Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Documentation  |   Version:
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * milestone:  => 1.2

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #13532: Error in F() object docs

[Django]

#13532: Error in F() object docs
---+
 Reporter:  erw|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 [http://docs.djangoproject.com/en/dev/topics/db/queries/#filters-can-
 reference-fields-on-the-model] says:

 "To find all the blog entries with twice as many comments as pingbacks, we
 modify the query:"
 {{{
 >>> Entry.objects.filter(n_pingbacks__lt=F('n_comments') * 2)
 }}}
 But the query should in fact have been:
 {{{
 >>> Entry.objects.filter(n_pingbacks=F('n_comments') / 2)
 }}}
 And to find entries with ''at least'' twice as many comments as pingbacks:
 {{{
 >>> Entry.objects.filter(n_pingbacks__lte=F('n_comments') / 2)
 }}}

 It would probably be easier to understand the sentences where comments
 come before pingbacks ("twice as many comments as pingbacks"), if they had
 the same order in the query. Again, to find entries with ''at least''
 twice as many comments as pingbacks:
 {{{
 >>> Entry.objects.filter(n_comments__gte=F('n_pingbacks') * 2)
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7539: Add ON DELETE and ON UPDATE support to Django

[Django]

#7539: Add ON DELETE and ON UPDATE support to Django
---+
  Reporter:  glassfordm| Owner: 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  feature
 Stage:  Design decision needed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by cgieringer):

 Related: #6870

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8168: Need another Pre Delete Signal Type (feature)

[Django]

#8168: Need another Pre Delete Signal Type (feature)
-+--
  Reporter:  magneto | Owner:  nobody 
Status:  closed  | Milestone: 
 Component:  Core framework  |   Version:  SVN
Resolution:  duplicate   |  Keywords:  signals
 Stage:  Design decision needed  | Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by cgieringer):

 Related: #6870

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6108: send all_objects_to_be_deleted in the pre_delete signal

[Django]

#6108: send all_objects_to_be_deleted in the pre_delete signal
--+-
  Reporter:  Gábor Farkas   | Owner:  
nobody
Status:  new  | Milestone:  
  
 Component:  Core framework   |   Version:  SVN 
  
Resolution:   |  Keywords:  
  
 Stage:  Design decision needed   | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  1|  
--+-
Changes (by cgieringer):

 * cc: cgieringer (added)

Comment:

 Related: #6870.  My two cents is that the signal's arguments are fine as-
 is, it just needs to be called at an earlier point in time.  Signals are
 simple and elegant; they tell you just enough information to find the rest
 of the information you might want.  Adding the list of to-be-deleted
 objects is unnecessary because a signal listener could create this list
 without the signal including it.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12034: Deleting an model instance doesn't call the delete() method of related instances (even though they are removed).

[Django]

#12034: Deleting an model instance doesn't call the delete() method of related
instances (even though they are removed).
---+
  Reporter:  ilblackdragon | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:  wontfix   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by cgieringer):

 Related: #6870

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6870: pre_delete should be sent before collecting ForeignKey relationships

[Django]

#6870: pre_delete should be sent before collecting ForeignKey relationships
-+--
  Reporter:  wkornewald  | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Changes (by cgieringer):

 * cc: cgieringer (added)
  * needs_docs:  0 => 1
  * has_patch:  0 => 1
  * needs_tests:  0 => 1

Comment:

 I agree with the ticket creator that django should send the pre_delete
 signal at a time when it is still possible to modify the model in a way
 that affects deletion.  It seems that the contract of all pre_xx signal
 should include informing listeners before any undoable changes have
 occurred in the deletion, save, etc.

 The most common usage for a correctly behaving pre_delete signal is
 apparently to remove related objects to prevent cascade deletion, and the
 feature requested in #7539 would eventually provide another means to that
 usage.  But that possible feature doesn't change the fact that pre_delete
 breaks its contract (or what it seems its contract should be) by
 collecting the related objects for deletion before informing listeners
 that the objects will be deleted, thereby offering no consistent way to
 prevent cascade deletion.  The only way to get around this limitation is
 to define both a custom model delete and manager delete for each model
 requiring this functionality, which is a tedious and error-prone
 requirement.

 Currently the pre_delete signal is sent from
 django.db.models.query.delete_objects.  The least-complicated place to
 send the signal while meeting its contract is from the beginning of
 _collect_sub_objects, because this is both the first place that related
 objects are seen (as that method traverses relations from the original
 model) and the last place that a change to a model's related objects can
 be made before they are cached in seen_objects and then sent for deletion.

 I have attached a patch which adds a pre_signal argument to
 django.db.model.base.Model's _collect_sub_objects.  The argument should be
 one of Django's signals from django.db.models.signals, and it will be
 called at the beginning of the method if the model was not autocreated.
 The argument is called pre_signal because although _collect_sub_objects is
 presently only used for finding related objects for deletion, it could
 possibly be used for some other purpose for which a different pre_xx
 signal should be sent.  The patch adds _collect_sub_objects(...,
 pre_signal=pre_signal) to recursions and _collect_sub_objects(...,
 pre_signal=pre_delete) to the two places the method is called.  It removes
 the sending of pre_delete from delete_objects.

 Thank you to all the Django developers, this framework is my favorite
 piece of software.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11604: ChangeList should pass depth=1 to .select_related()

[Django]

#11604: ChangeList should pass depth=1 to .select_related()
-+--
  Reporter:  rlaa...@wiktel.com  | Owner:  nobody 
Status:  new | Milestone:  1.3
 Component:  django.contrib.admin|   Version:  1.0
Resolution:  |  Keywords:  efficient-admin
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

  * milestone:  => 1.3

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12012: Integration with the Python standard library logging module

[Django]

#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Changes (by vinay_sa...@yahoo.co.uk):

  * milestone:  => 1.3

Comment:

 I've added a Launchpad branch which is an up-to-date branch of Django
 trunk (as at today - 13 May 2010), with updated logging functionality
 (including a copy of dictConfig, from my project of the same name which is
 a standalone version of the new PEP 391 logging configuration
 functionality, usable with Python 2.4, 2.5 and 2.6). I've inserted some
 logging statements in app loading, SQL execution and request handling
 (including handling of uncaught and other exceptions).

 There's also an example project which uses the Django logging API to
 configure logging in settings.py, via PEP 391-compatible configuration
 dictionary (the initialisation code is only called once, even though
 settings.py is imported at least twice).

 Bazaar branch for the version of Django with logging enabled:
 https://code.launchpad.net/~vinay-sajip/django/logging
 Bazaar branch for test project, which shows how logging can be configured:
 https://code.launchpad.net/~vinay-sajip/+junk/django-logtest

 The test app is set up to log to /tmp/logtest.log (which isn't spammed
 with SQL logging) and /tmp/logtest-sql.log (which contains the SQL
 statements executed).

 Basic diffs to show what was added:

 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/53 -
 Added callback hooks
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/55 -
 Added log module reference
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/56 -
 Added log module itself
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/55 -
 Removed log module reference (as not needed)
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/61 -
 Added dictconfig.py and changed code to use it
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/62 -
 Added useful default to configuration
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/63 -
 Added logging to app loading
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/65 -
 Added logging for SQL and uncaught exceptions in request handling
 http://bazaar.launchpad.net/~vinay-sajip/django/logging/revision/67 -
 Added some more logging to request handling code


 Your feedback will be appreciated, especially in terms of other parts of
 Django that you think would benefit particularly from having logging
 added.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #11604: ChangeList should pass depth=1 to .select_related()

[Django]

#11604: ChangeList should pass depth=1 to .select_related()
-+--
  Reporter:  rlaa...@wiktel.com  | Owner:  nobody 
Status:  new | Milestone: 
 Component:  django.contrib.admin|   Version:  1.0
Resolution:  |  Keywords:  efficient-admin
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by ishirav):

 Yes! Please please please apply this patch. We've seen ridiculous queries
 joining 20 or more tables needlessly, and MySQL hanging while trying to
 run these queries.

 As a temporary workaround, here's a way to override the select_related
 depth in the admin queryset:

 {{{
 class FoobarAdmin(admin.ModelAdmin):
 def queryset(self, request):
 qs = super(FoobarAdmin, self).queryset(request)
 return qs.select_related(depth=1)

 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13023: Don't show "+ Add another" in admin inlines when extra = 0

[Django]

#13023: Don't show "+ Add another" in admin inlines when extra = 0
---+
  Reporter:  rasca | Owner:  gabrielhurley
Status:  closed| Milestone:  1.2  
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:  fixed |  Keywords:   
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by carsongee):

 Replying to [comment:14 ramiro]:
 > Replying to [comment:13 carsongee]:
 > > Can we get this listed in the release notes for 1.2 as a backwards
 incompatible change?  I have an application that lets the user choose how
 many forms to have in a formset by storing a value in the database, and I
 had to go through source code for a quite a while when testing 1.2 rc1 for
 why all of the sudden I didn't have any forms in my formsets.  I may be an
 anomaly, but it could save some people time if it was in the release
 notes.
 >
 > Please review the patch attached to #13524 and suggest any changes you
 deem appropiate.
 The patch looks good to me.  Thanks for that.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #13531: django.core.files.File throws an exception on _get_size

[Django]

#13531: django.core.files.File throws an exception on _get_size
-+--
 Reporter:  aarond10 |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.2-beta  
 Keywords:  File, Exception  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The File _get_size() function incorrectly uses self.file.name as a path.

 When using a custom FileStorage like storage object, the files name and
 actual path may be different. This will trigger an AttributeError even
 though the file actually exists on disk and is readable.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r13253 - in django/branches/releases/1.1.X: django/views tests/regressiontests/admin_views tests/regressiontests/views tests/regressiontests/views/app1 tests/regressiontests/views/app1/loc

[noreply]

Author: russellm
Date: 2010-05-13 08:44:32 -0500 (Thu, 13 May 2010)
New Revision: 13253

Added:
   django/branches/releases/1.1.X/tests/regressiontests/views/app1/
   django/branches/releases/1.1.X/tests/regressiontests/views/app1/__init__.py
   django/branches/releases/1.1.X/tests/regressiontests/views/app1/locale/
   django/branches/releases/1.1.X/tests/regressiontests/views/app1/locale/fr/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app1/locale/fr/LC_MESSAGES/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app1/locale/fr/LC_MESSAGES/djangojs.mo
   
django/branches/releases/1.1.X/tests/regressiontests/views/app1/locale/fr/LC_MESSAGES/djangojs.po
   django/branches/releases/1.1.X/tests/regressiontests/views/app2/
   django/branches/releases/1.1.X/tests/regressiontests/views/app2/__init__.py
   django/branches/releases/1.1.X/tests/regressiontests/views/app2/locale/
   django/branches/releases/1.1.X/tests/regressiontests/views/app2/locale/fr/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app2/locale/fr/LC_MESSAGES/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app2/locale/fr/LC_MESSAGES/djangojs.mo
   
django/branches/releases/1.1.X/tests/regressiontests/views/app2/locale/fr/LC_MESSAGES/djangojs.po
   django/branches/releases/1.1.X/tests/regressiontests/views/app3/
   django/branches/releases/1.1.X/tests/regressiontests/views/app3/__init__.py
   django/branches/releases/1.1.X/tests/regressiontests/views/app3/locale/
   django/branches/releases/1.1.X/tests/regressiontests/views/app3/locale/es_AR/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app3/locale/es_AR/LC_MESSAGES/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app3/locale/es_AR/LC_MESSAGES/djangojs.mo
   
django/branches/releases/1.1.X/tests/regressiontests/views/app3/locale/es_AR/LC_MESSAGES/djangojs.po
   django/branches/releases/1.1.X/tests/regressiontests/views/app4/
   django/branches/releases/1.1.X/tests/regressiontests/views/app4/__init__.py
   django/branches/releases/1.1.X/tests/regressiontests/views/app4/locale/
   django/branches/releases/1.1.X/tests/regressiontests/views/app4/locale/es_AR/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app4/locale/es_AR/LC_MESSAGES/
   
django/branches/releases/1.1.X/tests/regressiontests/views/app4/locale/es_AR/LC_MESSAGES/djangojs.mo
   
django/branches/releases/1.1.X/tests/regressiontests/views/app4/locale/es_AR/LC_MESSAGES/djangojs.po
Modified:
   django/branches/releases/1.1.X/django/views/i18n.py
   django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py
   
django/branches/releases/1.1.X/tests/regressiontests/views/locale/es/LC_MESSAGES/djangojs.mo
   
django/branches/releases/1.1.X/tests/regressiontests/views/locale/es/LC_MESSAGES/djangojs.po
   
django/branches/releases/1.1.X/tests/regressiontests/views/locale/fr/LC_MESSAGES/djangojs.mo
   
django/branches/releases/1.1.X/tests/regressiontests/views/locale/fr/LC_MESSAGES/djangojs.po
   django/branches/releases/1.1.X/tests/regressiontests/views/tests/i18n.py
   django/branches/releases/1.1.X/tests/regressiontests/views/urls.py
Log:
[1.1.X] Fixed #13514 -- Corrected the process of loading multiple javascript 
translation catalogs. Thanks to jtiai for the report, to Ramiro Morales for 
working out the test case, and to Ramiro and Jannis for their help on the fix.

Backport of r13250 from trunk.

Modified: django/branches/releases/1.1.X/django/views/i18n.py
===
--- django/branches/releases/1.1.X/django/views/i18n.py 2010-05-13 13:42:24 UTC 
(rev 13252)
+++ django/branches/releases/1.1.X/django/views/i18n.py 2010-05-13 13:44:32 UTC 
(rev 13253)
@@ -163,13 +163,16 @@
 if en_catalog_missing:
 t = {}
 else:
+locale_t = {}
 for path in paths:
 try:
 catalog = gettext_module.translation(domain, path, 
[locale])
 except IOError:
 catalog = None
 if catalog is not None:
-t = catalog._catalog
+locale_t.update(catalog._catalog)
+if locale_t:
+t = locale_t
 src = [LibHead]
 plural = None
 if '' in t:

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py   
2010-05-13 13:42:24 UTC (rev 13252)
+++ django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py   
2010-05-13 13:44:32 UTC (rev 13253)
@@ -4,7 +4,6 @@
 import datetime
 from django.conf import settings
 from django.core.files import temp as tempfile
-from django.test import TestCase
 from django.contrib.auth.models import User, Permission
 from django.contrib.contenttypes.models import ContentType
 from dj

[Changeset] r13251 - django/trunk/django/conf/locale/de/LC_MESSAGES

[noreply]

Author: jezdez
Date: 2010-05-13 08:42:01 -0500 (Thu, 13 May 2010)
New Revision: 13251

Modified:
   django/trunk/django/conf/locale/de/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/de/LC_MESSAGES/django.po
Log:
Updated German translation.

Modified: django/trunk/django/conf/locale/de/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/de/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/de/LC_MESSAGES/django.po2010-05-13 
13:29:31 UTC (rev 13250)
+++ django/trunk/django/conf/locale/de/LC_MESSAGES/django.po2010-05-13 
13:42:01 UTC (rev 13251)
@@ -7,7 +7,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2010-05-05 00:38+0200\n"
+"POT-Creation-Date: 2010-05-13 15:30+0200\n"
 "PO-Revision-Date: 2010-04-26 13:53+0100\n"
 "Last-Translator: Jannis Leidel \n"
 "Language-Team: \n"
@@ -124,138 +124,142 @@
 msgstr "Ungarisch"
 
 #: conf/global_settings.py:70
+msgid "Indonesian"
+msgstr "Indonesisch"
+
+#: conf/global_settings.py:71
 msgid "Icelandic"
 msgstr "Isländisch"
 
-#: conf/global_settings.py:71
+#: conf/global_settings.py:72
 msgid "Italian"
 msgstr "Italienisch"
 
-#: conf/global_settings.py:72
+#: conf/global_settings.py:73
 msgid "Japanese"
 msgstr "Japanisch"
 
-#: conf/global_settings.py:73
+#: conf/global_settings.py:74
 msgid "Georgian"
 msgstr "Georgisch"
 
-#: conf/global_settings.py:74
+#: conf/global_settings.py:75
 msgid "Khmer"
 msgstr "Khmer"
 
-#: conf/global_settings.py:75
+#: conf/global_settings.py:76
 msgid "Kannada"
 msgstr "Kannada"
 
-#: conf/global_settings.py:76
+#: conf/global_settings.py:77
 msgid "Korean"
 msgstr "Koreanisch"
 
-#: conf/global_settings.py:77
+#: conf/global_settings.py:78
 msgid "Lithuanian"
 msgstr "Litauisch"
 
-#: conf/global_settings.py:78
+#: conf/global_settings.py:79
 msgid "Latvian"
 msgstr "Lettisch"
 
-#: conf/global_settings.py:79
+#: conf/global_settings.py:80
 msgid "Macedonian"
 msgstr "Mazedonisch"
 
-#: conf/global_settings.py:80
+#: conf/global_settings.py:81
 msgid "Mongolian"
 msgstr "Mongolisch"
 
-#: conf/global_settings.py:81
+#: conf/global_settings.py:82
 msgid "Dutch"
 msgstr "Holländisch"
 
-#: conf/global_settings.py:82
+#: conf/global_settings.py:83
 msgid "Norwegian"
 msgstr "Norwegisch"
 
-#: conf/global_settings.py:83
+#: conf/global_settings.py:84
 msgid "Norwegian Bokmal"
 msgstr "Norwegisch (Bokmål)"
 
-#: conf/global_settings.py:84
+#: conf/global_settings.py:85
 msgid "Norwegian Nynorsk"
 msgstr "Norwegisch (Nynorsk)"
 
-#: conf/global_settings.py:85
+#: conf/global_settings.py:86
 msgid "Polish"
 msgstr "Polnisch"
 
-#: conf/global_settings.py:86
+#: conf/global_settings.py:87
 msgid "Portuguese"
 msgstr "Portugiesisch"
 
-#: conf/global_settings.py:87
+#: conf/global_settings.py:88
 msgid "Brazilian Portuguese"
 msgstr "Brasilianisches Portugiesisch"
 
-#: conf/global_settings.py:88
+#: conf/global_settings.py:89
 msgid "Romanian"
 msgstr "Rumänisch"
 
-#: conf/global_settings.py:89
+#: conf/global_settings.py:90
 msgid "Russian"
 msgstr "Russisch"
 
-#: conf/global_settings.py:90
+#: conf/global_settings.py:91
 msgid "Slovak"
 msgstr "Slowakisch"
 
-#: conf/global_settings.py:91
+#: conf/global_settings.py:92
 msgid "Slovenian"
 msgstr "Slowenisch"
 
-#: conf/global_settings.py:92
+#: conf/global_settings.py:93
 msgid "Albanian"
 msgstr "Albanisch"
 
-#: conf/global_settings.py:93
+#: conf/global_settings.py:94
 msgid "Serbian"
 msgstr "Serbisch"
 
-#: conf/global_settings.py:94
+#: conf/global_settings.py:95
 msgid "Serbian Latin"
 msgstr "Serbisch (Latein)"
 
-#: conf/global_settings.py:95
+#: conf/global_settings.py:96
 msgid "Swedish"
 msgstr "Schwedisch"
 
-#: conf/global_settings.py:96
+#: conf/global_settings.py:97
 msgid "Tamil"
 msgstr "Tamilisch"
 
-#: conf/global_settings.py:97
+#: conf/global_settings.py:98
 msgid "Telugu"
 msgstr "Telugisch"
 
-#: conf/global_settings.py:98
+#: conf/global_settings.py:99
 msgid "Thai"
 msgstr "Thailändisch"
 
-#: conf/global_settings.py:99
+#: conf/global_settings.py:100
 msgid "Turkish"
 msgstr "Türkisch"
 
-#: conf/global_settings.py:100
+#: conf/global_settings.py:101
 msgid "Ukrainian"
 msgstr "Ukrainisch"
 
-#: conf/global_settings.py:101
+#: conf/global_settings.py:102
 msgid "Vietnamese"
 msgstr "Vietnamesisch"
 
-#: conf/global_settings.py:102
+#: conf/global_settings.py:103
 msgid "Simplified Chinese"
 msgstr "Vereinfachtes Chinesisch"
 
-#: conf/global_settings.py:103
+#: conf/global_settings.py:104
 msgid "Traditional Chinese"
 msgstr "Traditionelles Chinesisch"
 
@@ -361,7 +365,7 @@
 msgstr "%s geändert."
 
 #: contrib/admin/options.py:559 contrib/admin/options.py:569
-#: contrib/comments/templates/comments/preview.html:16 db/models/base.py:844
+#: contrib/comments/templates/comments/preview.html:16 db/models/base.py:845
 #: for

[Changeset] r13250 - in django/trunk: django/views tests/regressiontests/admin_views tests/regressiontests/views tests/regressiontests/views/app1 tests/regressiontests/views/app1/locale tests/regressi

[noreply]

Author: russellm
Date: 2010-05-13 08:29:31 -0500 (Thu, 13 May 2010)
New Revision: 13250

Added:
   django/trunk/tests/regressiontests/views/app1/
   django/trunk/tests/regressiontests/views/app1/__init__.py
   django/trunk/tests/regressiontests/views/app1/locale/
   django/trunk/tests/regressiontests/views/app1/locale/fr/
   django/trunk/tests/regressiontests/views/app1/locale/fr/LC_MESSAGES/
   
django/trunk/tests/regressiontests/views/app1/locale/fr/LC_MESSAGES/djangojs.mo
   
django/trunk/tests/regressiontests/views/app1/locale/fr/LC_MESSAGES/djangojs.po
   django/trunk/tests/regressiontests/views/app2/
   django/trunk/tests/regressiontests/views/app2/__init__.py
   django/trunk/tests/regressiontests/views/app2/locale/
   django/trunk/tests/regressiontests/views/app2/locale/fr/
   django/trunk/tests/regressiontests/views/app2/locale/fr/LC_MESSAGES/
   
django/trunk/tests/regressiontests/views/app2/locale/fr/LC_MESSAGES/djangojs.mo
   
django/trunk/tests/regressiontests/views/app2/locale/fr/LC_MESSAGES/djangojs.po
   django/trunk/tests/regressiontests/views/app3/
   django/trunk/tests/regressiontests/views/app3/__init__.py
   django/trunk/tests/regressiontests/views/app3/locale/
   django/trunk/tests/regressiontests/views/app3/locale/es_AR/
   django/trunk/tests/regressiontests/views/app3/locale/es_AR/LC_MESSAGES/
   
django/trunk/tests/regressiontests/views/app3/locale/es_AR/LC_MESSAGES/djangojs.mo
   
django/trunk/tests/regressiontests/views/app3/locale/es_AR/LC_MESSAGES/djangojs.po
   django/trunk/tests/regressiontests/views/app4/
   django/trunk/tests/regressiontests/views/app4/__init__.py
   django/trunk/tests/regressiontests/views/app4/locale/
   django/trunk/tests/regressiontests/views/app4/locale/es_AR/
   django/trunk/tests/regressiontests/views/app4/locale/es_AR/LC_MESSAGES/
   
django/trunk/tests/regressiontests/views/app4/locale/es_AR/LC_MESSAGES/djangojs.mo
   
django/trunk/tests/regressiontests/views/app4/locale/es_AR/LC_MESSAGES/djangojs.po
Modified:
   django/trunk/django/views/i18n.py
   django/trunk/tests/regressiontests/admin_views/tests.py
   django/trunk/tests/regressiontests/views/locale/es/LC_MESSAGES/djangojs.mo
   django/trunk/tests/regressiontests/views/locale/es/LC_MESSAGES/djangojs.po
   django/trunk/tests/regressiontests/views/locale/fr/LC_MESSAGES/djangojs.mo
   django/trunk/tests/regressiontests/views/locale/fr/LC_MESSAGES/djangojs.po
   django/trunk/tests/regressiontests/views/locale/ru/LC_MESSAGES/djangojs.mo
   django/trunk/tests/regressiontests/views/locale/ru/LC_MESSAGES/djangojs.po
   django/trunk/tests/regressiontests/views/tests/i18n.py
   django/trunk/tests/regressiontests/views/urls.py
Log:
Fixed #13514 -- Corrected the process of loading multiple javascript 
translation catalogs. Thanks to jtiai for the report, to Ramiro Morales for 
working out the test case, and to Ramiro and Jannis for their help on the fix.

Modified: django/trunk/django/views/i18n.py
===
--- django/trunk/django/views/i18n.py   2010-05-13 11:11:27 UTC (rev 13249)
+++ django/trunk/django/views/i18n.py   2010-05-13 13:29:31 UTC (rev 13250)
@@ -213,13 +213,16 @@
 if en_catalog_missing:
 t = {}
 else:
+locale_t = {}
 for path in paths:
 try:
 catalog = gettext_module.translation(domain, path, 
[locale])
 except IOError:
 catalog = None
 if catalog is not None:
-t = catalog._catalog
+locale_t.update(catalog._catalog)
+if locale_t:
+t = locale_t
 src = [LibHead]
 plural = None
 if '' in t:

Modified: django/trunk/tests/regressiontests/admin_views/tests.py
===
--- django/trunk/tests/regressiontests/admin_views/tests.py 2010-05-13 
11:11:27 UTC (rev 13249)
+++ django/trunk/tests/regressiontests/admin_views/tests.py 2010-05-13 
13:29:31 UTC (rev 13250)
@@ -4,7 +4,6 @@
 import datetime
 from django.conf import settings
 from django.core.files import temp as tempfile
-from django.test import TestCase
 from django.contrib.auth import admin # Register auth models with the admin.
 from django.contrib.auth.models import User, Permission, UNUSABLE_PASSWORD
 from django.contrib.contenttypes.models import ContentType
@@ -13,15 +12,16 @@
 from django.contrib.admin.util import quote
 from django.contrib.admin.helpers import ACTION_CHECKBOX_NAME
 from django.forms.util import ErrorList
+from django.test import TestCase
 from django.utils import formats
 from django.utils.cache import get_max_age
+from django.utils.encoding import iri_to_uri
 from django.utils.html import escape
 from django.utils.translation import get_date_formats, activate, deactivate
-from django.utils.encoding import iri_to_uri
 
 # local test models
 from models import Article, BarAccount, Cu

Re: [Django] #13514: Only last package javascript catalog is loaded in case of missing default translation.

[Django]

#13514: Only last package javascript catalog is loaded in case of missing 
default
translation.
---+
  Reporter:  jtiai | Owner:  nobody 
Status:  new   | Milestone:  1.2
 Component:  Internationalization  |   Version:  SVN
Resolution:|  Keywords:  i18n javascript
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Replying to [comment:1 arkx]:

 > I fixed this by setting a flag if English translation files could not be
 found during the catalog's construction and checking for that flag when at
 the last step the system is looking for active language's translation
 files and the language happens to be English. Then and only then is the
 catalog that had been set to LANGUAGE_CODE in previous step discarded.
 Note that '''nothing is discarded unless the English translation files are
 missing and English is the currently activated language choice''', which
 should not happen if a browser requests the Finnish translation.

 So far I've found that undoing the
 [http://code.djangoproject.com/changeset/13069#file0 change] to
 `django/views/i18n.py:javascript_catalog()` from r13069 makes the tests
 pass as someone suggested above, both the ones added to this ticket and
 even the ones added in that same commit. The full suite run successfully
 too.

 arkx:

 What I'd like to understand and make sure we are handling correctly is
 that `en_catalog_missing` flag. Currently we are setting it to True when
 ''at least'' one of the Python packages contained in the ''packages''
 parameter has no English `.mo` file. This means the LANGUAGE_CODE
 translations will be discarded in such case. Is this correct?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r13249 - django/trunk/django/utils

[noreply]

Author: lukeplant
Date: 2010-05-13 06:11:27 -0500 (Thu, 13 May 2010)
New Revision: 13249

Modified:
   django/trunk/django/utils/decorators.py
Log:
Corrected 'name' of functions wrapped with method_decorator



Modified: django/trunk/django/utils/decorators.py
===
--- django/trunk/django/utils/decorators.py 2010-05-12 23:00:57 UTC (rev 
13248)
+++ django/trunk/django/utils/decorators.py 2010-05-13 11:11:27 UTC (rev 
13249)
@@ -22,7 +22,7 @@
 return wraps(func)(_wrapper)
 update_wrapper(_dec, decorator)
 # Change the name to aid debugging.
-_dec.__name__ = 'method_dec(%s)' % decorator.__name__
+_dec.__name__ = 'method_decorator(%s)' % decorator.__name__
 return _dec
 
 
@@ -50,6 +50,7 @@
 """
 return make_middleware_decorator(middleware_class)()
 
+
 def available_attrs(fn):
 """
 Return the list of functools-wrappable attributes on a callable.
@@ -57,6 +58,7 @@
 """
 return tuple(a for a in WRAPPER_ASSIGNMENTS if hasattr(fn, a))
 
+
 def make_middleware_decorator(middleware_class):
 def _make_decorator(*m_args, **m_kwargs):
 middleware = middleware_class(*m_args, **m_kwargs)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6735: Class-based generic views

[Django]

#6735: Class-based generic views
+---
  Reporter:  jkocherhans| Owner:  telenieko
Status:  assigned   | Milestone:   
 Component:  Generic views  |   Version:   
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

 * cc: dr...@dokterbob.net (added)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.