Re: [Django] #17049: The test suite should be deprecation-warning clean

[Django]

#17049: The test suite should be deprecation-warning clean
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Alex):

 * version:  1.3 => SVN
 * component:  Uncategorized => Testing framework
 * stage:  Unreviewed => Accepted


-- 
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-updates@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] #17049: The test suite should be deprecation-warning clean

[Django]

#17049: The test suite should be deprecation-warning clean
+
   Reporter:  carljm|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |Version:  1.3
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Right now running the test suite with -Wall results in quite a few
 warnings. Really, when we deprecate something, we should modify its tests
 to use the catch_warnings context manager and test for the deprecation
 warning, as well as preventing it from bubbling up to the test suite.

 Unfortunately catch_warnings is Python 2.6+. Since this probably isn't
 important enough to warrant a backport, just leaving this ticket as a
 reminder to clean this up once we hit 2.6 as minimum supported Python
 version.

-- 
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-updates@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] #17046: User.objects.create_user() allows empty usernames

[Django]

#17046: User.objects.create_user() allows empty usernames
--+
 Reporter:  honza |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by ptone):

 * needs_better_patch:   => 1
 * needs_tests:   => 1
 * version:  1.3 => SVN
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I do think the manager function should validate the model - attached is a
 very quick patch that does this - it is not a complete patch

-- 
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-updates@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] r16985 - in django/trunk: django/contrib/auth django/utils tests/regressiontests/admin_views

[noreply]

Author: Alex
Date: 2011-10-13 17:20:50 -0700 (Thu, 13 Oct 2011)
New Revision: 16985

Modified:
   django/trunk/django/contrib/auth/forms.py
   django/trunk/django/utils/itercompat.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Remove the usage of deprecated function in Django. Also simplify the fallback 
code.

Modified: django/trunk/django/contrib/auth/forms.py
===
--- django/trunk/django/contrib/auth/forms.py   2011-10-14 00:16:14 UTC (rev 
16984)
+++ django/trunk/django/contrib/auth/forms.py   2011-10-14 00:20:50 UTC (rev 
16985)
@@ -1,7 +1,6 @@
 from django import forms
 from django.template import loader
 from django.utils.http import int_to_base36
-from django.utils.itercompat import any
 from django.utils.translation import ugettext_lazy as _
 
 from django.contrib.auth.models import User

Modified: django/trunk/django/utils/itercompat.py
===
--- django/trunk/django/utils/itercompat.py 2011-10-14 00:16:14 UTC (rev 
16984)
+++ django/trunk/django/utils/itercompat.py 2011-10-14 00:20:50 UTC (rev 
16985)
@@ -4,6 +4,7 @@
 these implementations if necessary.
 """
 
+import __builtin__
 import itertools
 import warnings
 
@@ -36,15 +37,9 @@
 def all(iterable):
 warnings.warn("django.utils.itercompat.all is deprecated; use the native 
version instead",
   PendingDeprecationWarning)
-for item in iterable:
-if not item:
-return False
-return True
+return __builtin__.all(iterable)
 
 def any(iterable):
 warnings.warn("django.utils.itercompat.any is deprecated; use the native 
version instead",
   PendingDeprecationWarning)
-for item in iterable:
-if item:
-return True
-return False
+return __builtin__.any(iterable)

Modified: django/trunk/tests/regressiontests/admin_views/tests.py
===
--- django/trunk/tests/regressiontests/admin_views/tests.py 2011-10-14 
00:16:14 UTC (rev 16984)
+++ django/trunk/tests/regressiontests/admin_views/tests.py 2011-10-14 
00:20:50 UTC (rev 16985)
@@ -135,7 +135,7 @@
 'date_1': u'14:55:39',
 }
 response = self.client.post('/test_admin/%s/admin_views/article/add/' 
% self.urlbit, post_data)
-self.failUnlessEqual(response.status_code, 200)
+self.assertEqual(response.status_code, 200)
 self.assertContains(response, 'dismissAddAnotherPopup')
 self.assertContains(response, 'title with a new\u000Aline')
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] r16984 - in django/trunk/docs: ref releases

[noreply]

Author: lukeplant
Date: 2011-10-13 17:16:14 -0700 (Thu, 13 Oct 2011)
New Revision: 16984

Modified:
   django/trunk/docs/ref/databases.txt
   django/trunk/docs/releases/1.3-beta-1.txt
Log:
Fixed ReST indentation errors introduced in [16983]. Grr.

Modified: django/trunk/docs/ref/databases.txt
===
--- django/trunk/docs/ref/databases.txt 2011-10-14 00:12:01 UTC (rev 16983)
+++ django/trunk/docs/ref/databases.txt 2011-10-14 00:16:14 UTC (rev 16984)
@@ -726,11 +726,11 @@
 * LOB columns may not be used in indexes.
 
 * LOB columns may not be used in a ``SELECT DISTINCT`` list. This means that
-attempting to use the ``QuerySet.distinct`` method on a model that
-includes ``TextField`` columns will result in an error when run against
-Oracle. As a workaround, use the ``QuerySet.defer`` method in conjunction
-with ``distinct()`` to prevent ``TextField`` columns from being included in
-the ``SELECT DISTINCT`` list.
+  attempting to use the ``QuerySet.distinct`` method on a model that
+  includes ``TextField`` columns will result in an error when run against
+  Oracle. As a workaround, use the ``QuerySet.defer`` method in conjunction
+  with ``distinct()`` to prevent ``TextField`` columns from being included in
+  the ``SELECT DISTINCT`` list.
 
 .. _third-party-notes:
 

Modified: django/trunk/docs/releases/1.3-beta-1.txt
===
--- django/trunk/docs/releases/1.3-beta-1.txt   2011-10-14 00:12:01 UTC (rev 
16983)
+++ django/trunk/docs/releases/1.3-beta-1.txt   2011-10-14 00:16:14 UTC (rev 
16984)
@@ -101,24 +101,24 @@
 As a result, we took the following steps to rectify the issue:
 
 * Two new global settings were added that will be used by, **but are not
-limited to**, the :doc:`staticfiles` app:
+  limited to**, the :doc:`staticfiles` app:
 
 * :setting:`STATIC_ROOT` (formally ``STATICFILES_ROOT``)
 
 * :setting:`STATIC_URL` (formally ``STATICFILES_URL``)
 
 * The 
``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
-template tag was moved to Django's core (``django.templatetags.static``) and
-renamed to :ttag:`get_static_prefix`.
+  template tag was moved to Django's core (``django.templatetags.static``) and
+  renamed to :ttag:`get_static_prefix`.
 
 * The ``django.contrib.staticfiles.context_processors.staticfiles``
-context processor was moved to Django's core
-(``django.core.context_processors.static``) and renamed to
-:func:`~django.core.context_processors.static`.
+  context processor was moved to Django's core
+  (``django.core.context_processors.static``) and renamed to
+  :func:`~django.core.context_processors.static`.
 
 * :ref:`form-media-paths` now uses :setting:`STATIC_URL` as the prefix
-**if the value is not None**, and falls back to the previously used
-:setting:`MEDIA_URL` setting otherwise.
+  **if the value is not None**, and falls back to the previously used
+  :setting:`MEDIA_URL` setting otherwise.
 
 Changes to the login methods of the admin
 ~

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #13843: 'destroy_geom' filling up the apache error logs.

[Django]

#13843: 'destroy_geom' filling up the apache error logs.
---+--
 Reporter:  Rozza  |Owner:  nobody
 Type:  Uncategorized  |   Status:  reopened
Component:  GIS|  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 Replying to [comment:4 anonymous]:
 > Replying to [comment:3 kamikaze.is.waiting.you@…]:
 > > Having same problem when editing polygon (from geodjango tutorial of
 World) in admin part.
 > And this doesn't happen every time...

 [Fri Oct 14 01:39:24 2011] [notice] caught SIGTERM, shutting down
 [Fri Oct 14 01:39:24 2011] [error] Exception AttributeError: "'NoneType'
 object has no attribute 'finishGEOS_r'" in > ignored
 [Fri Oct 14 01:39:24 2011] [error] Exception AttributeError: "'NoneType'
 object has no attribute 'finishGEOS_r'" in > ignored
 [Fri Oct 14 01:39:24 2011] [error] Exception AttributeError: "'NoneType'
 object has no attribute 'destroy_geom'" in Exception AttributeError:
 "'NoneType' object has no attribute 'destroy_geom'" in
 [Fri Oct 14 01:39:24 2011] [error] Exception AttributeError: "'NoneType'
 object has no attribute 'destroy_geom'" in Exception AttributeError:
 "'NoneType' object has no attribute 'destroy_geom'" in

-- 
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-updates@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] #13843: 'destroy_geom' filling up the apache error logs.

[Django]

#13843: 'destroy_geom' filling up the apache error logs.
---+--
 Reporter:  Rozza  |Owner:  nobody
 Type:  Uncategorized  |   Status:  reopened
Component:  GIS|  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 Replying to [comment:3 kamikaze.is.waiting.you@…]:
 > Having same problem when editing polygon (from geodjango tutorial of
 World) in admin part.
 And this doesn't happen every time...

-- 
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-updates@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] #13843: 'destroy_geom' filling up the apache error logs.

[Django]

#13843: 'destroy_geom' filling up the apache error logs.
---+--
 Reporter:  Rozza  |Owner:  nobody
 Type:  Uncategorized  |   Status:  reopened
Component:  GIS|  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by kamikaze.is.waiting.you@…):

 * status:  closed => reopened
 * severity:   => Normal
 * type:   => Uncategorized
 * needs_tests:  0 => 1
 * version:  1.2 => 1.3
 * easy:   => 0
 * has_patch:  1 => 0
 * ui_ux:   => 0
 * resolution:  wontfix =>


Comment:

 Having same problem when editing polygon (from geodjango tutorial of
 World) in admin part.

-- 
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-updates@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] #7616: fcgi and socket file permissions

[Django]

#7616: fcgi and socket file permissions
-+-
 Reporter:  mtredinnick  |Owner:
 Type:  Uncategorized|  gabrielhurley
Component:  Documentation|   Status:  closed
 Severity:  Normal   |  Version:  SVN
 Keywords:  deployment   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by joerg@…):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Wouldn't it be a better idea to apply the patch from #14958? It does allow
 safely specifying the umask without further hacks.

-- 
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-updates@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] r16982 - django/trunk/tests/regressiontests/forms/tests

[noreply]

Author: Alex
Date: 2011-10-13 14:44:58 -0700 (Thu, 13 Oct 2011)
New Revision: 16982

Modified:
   django/trunk/tests/regressiontests/forms/tests/__init__.py
Log:
Fix a Python 2.5-ism.

Modified: django/trunk/tests/regressiontests/forms/tests/__init__.py
===
--- django/trunk/tests/regressiontests/forms/tests/__init__.py  2011-10-13 
21:34:56 UTC (rev 16981)
+++ django/trunk/tests/regressiontests/forms/tests/__init__.py  2011-10-13 
21:44:58 UTC (rev 16982)
@@ -1,14 +1,21 @@
 from __future__ import absolute_import
 
-from .error_messages import *
-from .extra import *
+from .error_messages import (FormsErrorMessagesTestCase,
+ModelChoiceFieldErrorMessagesTestCase)
+from .extra import FormsExtraTestCase, FormsExtraL10NTestCase
 from .fields import FieldsTests
-from .forms import *
-from .formsets import *
-from .input_formats import *
-from .media import *
-from .models import *
-from .regressions import *
-from .util import *
+from .forms import FormsTestCase
+from .formsets import (FormsFormsetTestCase, FormsetAsFooTests,
+TestIsBoundBehavior, TestEmptyFormSet)
+from .input_formats import (LocalizedTimeTests, CustomTimeInputFormatsTests,
+SimpleTimeFormatTests, LocalizedDateTests, CustomDateInputFormatsTests,
+SimpleDateFormatTests, LocalizedDateTimeTests,
+CustomDateTimeInputFormatsTests, SimpleDateTimeFormatTests)
+from .media import FormsMediaTestCase, StaticFormsMediaTestCase
+from .models import (TestTicket12510, ModelFormCallableModelDefault,
+FormsModelTestCase, RelatedModelFormTests)
+from .regressions import FormsRegressionsTestCase
+from .util import FormsUtilTestCase
 from .validators import TestFieldWithValidators
-from .widgets import *
+from .widgets import (FormsWidgetTestCase, FormsI18NWidgetsTestCase,
+WidgetTests, ClearableFileInputTests)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #2626: Datetime handling is broken when dealing with more than one time zone

[Django]

#2626: Datetime handling is broken when dealing with more than one time zone
--+-
 Reporter:  Tom Tobin |Owner:  aaugustin
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by davidfstr):

 * cc: davidfstr (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-updates@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] #2626: Datetime handling is broken when dealing with more than one time zone

[Django]

#2626: Datetime handling is broken when dealing with more than one time zone
--+-
 Reporter:  Tom Tobin |Owner:  aaugustin
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 More details here: http://groups.google.com/group/django-
 developers/browse_thread/thread/cf0423bbb85b1bbf

-- 
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-updates@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] #16899: Wrong offset for Europe/Moscow

[Django]

#16899: Wrong offset for Europe/Moscow
--+
 Reporter:  igor@…|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:  timezone  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 Note that I have only fixed the issue originally described in this ticket.

 I intend to review `django.utils.tzinfo` in the context of my work on
 #2626.

-- 
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-updates@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] #17048: Add Docs for Guidelines for Upgrading an Existing Project's Django

[Django]

#17048: Add Docs for Guidelines for Upgrading an Existing Project's Django
---+
 Reporter:  dstufft|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  upgrading  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by carljm):

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


Comment:

 We already have a note about running with `-Wall` on the testing page, but
 that's not a place someone upgrading is likely to look. I think a short
 "Django upgrade checklist" page would be a good addition to the docs.

-- 
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-updates@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] r16980 - in django/trunk: django/utils tests/regressiontests/utils

[noreply]

Author: aaugustin
Date: 2011-10-13 14:19:48 -0700 (Thu, 13 Oct 2011)
New Revision: 16980

Modified:
   django/trunk/django/utils/tzinfo.py
   django/trunk/tests/regressiontests/utils/tzinfo.py
Log:
Fixed #16899 -- Backported the fix for http://bugs.python.org/issue9063 and 
added a test.


Modified: django/trunk/django/utils/tzinfo.py
===
--- django/trunk/django/utils/tzinfo.py 2011-10-13 19:39:46 UTC (rev 16979)
+++ django/trunk/django/utils/tzinfo.py 2011-10-13 21:19:48 UTC (rev 16980)
@@ -57,7 +57,9 @@
 return None
 
 def _isdst(self, dt):
-tt = (dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second, 
dt.weekday(), 0, -1)
+tt = (dt.year, dt.month, dt.day,
+  dt.hour, dt.minute, dt.second,
+  dt.weekday(), 0, 0)
 try:
 stamp = time.mktime(tt)
 except (OverflowError, ValueError):

Modified: django/trunk/tests/regressiontests/utils/tzinfo.py
===
--- django/trunk/tests/regressiontests/utils/tzinfo.py  2011-10-13 19:39:46 UTC 
(rev 16979)
+++ django/trunk/tests/regressiontests/utils/tzinfo.py  2011-10-13 21:19:48 UTC 
(rev 16980)
@@ -1,9 +1,35 @@
-import unittest
+import datetime
+import os
+import time
+from django.utils.tzinfo import FixedOffset, LocalTimezone
+from django.utils import unittest
 
-from django.utils.tzinfo import FixedOffset
-
 class TzinfoTests(unittest.TestCase):
 
+@classmethod
+def setUpClass(cls):
+cls.old_TZ = os.environ.get('TZ')
+os.environ['TZ'] = 'US/Eastern'
+
+try:
+# Check if a timezone has been set
+time.tzset()
+cls.tz_tests = True
+except AttributeError:
+# No timezone available. Don't run the tests that require a TZ
+cls.tz_tests = False
+
+@classmethod
+def tearDownClass(cls):
+if cls.old_TZ is None:
+del os.environ['TZ']
+else:
+os.environ['TZ'] = cls.old_TZ
+
+# Cleanup - force re-evaluation of TZ environment variable.
+if cls.tz_tests:
+time.tzset()
+
 def test_fixedoffset(self):
 self.assertEqual(repr(FixedOffset(0)), '+')
 self.assertEqual(repr(FixedOffset(60)), '+0100')
@@ -16,3 +42,21 @@
 self.assertEqual(repr(FixedOffset(5.5*60)), '+0530')
 self.assertEqual(repr(FixedOffset(-.5*60)), '-0030')
 self.assertEqual(repr(FixedOffset(.5*60)), '+0030')
+
+def test_16899(self):
+if not self.tz_tests:
+return
+ts = 1289106000
+# Midnight at the end of DST in US/Eastern: 2010-11-07T05:00:00Z
+dt = datetime.datetime.utcfromtimestamp(ts)
+# US/Eastern -- we force its representation to "EST"
+tz = LocalTimezone(dt + datetime.timedelta(days=1))
+self.assertEqual(
+repr(datetime.datetime.fromtimestamp(ts - 3600, tz)),
+'datetime.datetime(2010, 11, 7, 0, 0, tzinfo=EST)')
+self.assertEqual(
+repr(datetime.datetime.fromtimestamp(ts, tz)),
+'datetime.datetime(2010, 11, 7, 1, 0, tzinfo=EST)')
+self.assertEqual(
+repr(datetime.datetime.fromtimestamp(ts + 3600, tz)),
+'datetime.datetime(2010, 11, 7, 1, 0, tzinfo=EST)')

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #16899: Wrong offset for Europe/Moscow

[Django]

#16899: Wrong offset for Europe/Moscow
--+
 Reporter:  igor@…|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:  timezone  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16980]:
 {{{
 #!CommitTicketReference repository="" revision="16980"
 Fixed #16899 -- Backported the fix for http://bugs.python.org/issue9063
 and added a test.
 }}}

-- 
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-updates@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] #17048: Add Docs for Guidelines for Upgrading an Existing Project's Django

[Django]

#17048: Add Docs for Guidelines for Upgrading an Existing Project's Django
---+---
 Reporter:  dstufft|  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Documentation  |Version:  SVN
 Severity:  Normal |   Keywords:  upgrading
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+---
 A decent addition to the docs would be a short page about the general
 process to go about replacing a projects version of django with a new one.

 It would include any concerns/considerations that a developer should look
 at when doing the upgrade. One such thing is that starting with python
 2.7, Deprecation warnings are silenced by default (the thinking being that
 end users don't care about them). So when upgrading Django you should use
 something like ``python -Wall manage.py test`` or ``python -Wd manage.py
 test`` to check for any warnings.

-- 
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-updates@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] #17047: django.db.utils.load_backend gives confusing error for unqualified db backend name

[Django]

#17047: django.db.utils.load_backend gives confusing error for unqualified db
backend name
-+-
   Reporter:  carljm |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  SVN
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 If someone upgrades to trunk/1.4, missed the deprecation warnings, and
 still has e.g. "sqlite3" for a database ENGINE setting, the error message
 they get is a completely opaque "ImportError: no module named base"

 `load_backend` goes to some lengths to give a helpful error message in the
 case of a totally bogus backend, but oddly in the case of a backend that
 is not fully-qualified but does exist, it bails with the comment "this
 must be an error in Django itself." That comment/code is just wrong - it
 would be easy to add a helpful error message for this case.

-- 
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-updates@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] #13760: Management commands should not specify the default value twice

[Django]

#13760: Management commands should not specify the default value twice
-+-
 Reporter:  PaulM|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.2
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * has_patch:  0 => 1
 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Accepted => Ready for checkin


-- 
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-updates@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] #10080: call_command doesn't take into account command's default options

[Django]

#10080: call_command doesn't take into account command's default options
--+
 Reporter:  alexkoshelev  |Owner:  alexkoshelev
 Type:  Bug   |   Status:  reopened
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * ui_ux:   => 0
 * easy:   => 0
 * needs_tests:  1 => 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-updates@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] r16979 - django/trunk/django/core/serializers

[noreply]

Author: aaugustin
Date: 2011-10-13 12:39:46 -0700 (Thu, 13 Oct 2011)
New Revision: 16979

Modified:
   django/trunk/django/core/serializers/base.py
Log:
Fixed #16923 -- Removed unused method in the serialization code.


Modified: django/trunk/django/core/serializers/base.py
===
--- django/trunk/django/core/serializers/base.py2011-10-13 19:23:45 UTC 
(rev 16978)
+++ django/trunk/django/core/serializers/base.py2011-10-13 19:39:46 UTC 
(rev 16979)
@@ -57,12 +57,6 @@
 self.end_serialization()
 return self.getvalue()
 
-def get_string_value(self, obj, field):
-"""
-Convert a field's value to a string.
-"""
-return smart_unicode(field.value_to_string(obj))
-
 def start_serialization(self):
 """
 Called when serializing of the queryset starts.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #16923: Remove dead code: Serializer.get_string_value

[Django]

#16923: Remove dead code: Serializer.get_string_value
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Core |   Resolution:  fixed
  (Serialization)| Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16979]:
 {{{
 #!CommitTicketReference repository="" revision="16979"
 Fixed #16923 -- Removed unused method in the serialization code.
 }}}

-- 
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-updates@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] #2539: Custom tags and filters can be restricted by namespace

[Django]

#2539: Custom tags and filters can be restricted by namespace
-+
 Reporter:  limodou@…|Owner:
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  djangocon| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by anonymous):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 This would be a fantastic addition.  Coming from Grails, all of the
 taglib's there allow a namespace and it is extremely helpful in
 organization and maintenance of a project.

-- 
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-updates@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] r16978 - in django/trunk: django/contrib/admin django/contrib/auth django/contrib/sitemaps/tests django/db/backends django/db/backends/sqlite3 django/db/models/fields tests/regressiontest

[noreply]

Author: aaugustin
Date: 2011-10-13 12:23:45 -0700 (Thu, 13 Oct 2011)
New Revision: 16978

Modified:
   django/trunk/django/contrib/admin/filters.py
   django/trunk/django/contrib/auth/tokens.py
   django/trunk/django/contrib/sitemaps/tests/basic.py
   django/trunk/django/db/backends/__init__.py
   django/trunk/django/db/backends/sqlite3/base.py
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/tests/regressiontests/admin_filters/tests.py
Log:
Fixed #16906 -- Format datetimes with str/unicode instead of strftime where 
possible: it's faster and it works for all dates.

Also ensured that datetime_safe is used wherever strftime is called on 
dates/datetimes that may be before 1900.


Modified: django/trunk/django/contrib/admin/filters.py
===
--- django/trunk/django/contrib/admin/filters.py2011-10-13 19:18:27 UTC 
(rev 16977)
+++ django/trunk/django/contrib/admin/filters.py2011-10-13 19:23:45 UTC 
(rev 16978)
@@ -281,9 +281,9 @@
 
 today = datetime.date.today()
 one_week_ago = today - datetime.timedelta(days=7)
-today_str = (isinstance(self.field, models.DateTimeField)
-and today.strftime('%Y-%m-%d 23:59:59')
-or today.strftime('%Y-%m-%d'))
+today_str = str(today)
+if isinstance(self.field, models.DateTimeField):
+today_str += ' 23:59:59'
 
 self.lookup_kwarg_year = '%s__year' % self.field_path
 self.lookup_kwarg_month = '%s__month' % self.field_path
@@ -299,7 +299,7 @@
 self.lookup_kwarg_day: str(today.day),
 }),
 (_('Past 7 days'), {
-self.lookup_kwarg_past_7_days_gte: 
one_week_ago.strftime('%Y-%m-%d'),
+self.lookup_kwarg_past_7_days_gte: str(one_week_ago),
 self.lookup_kwarg_past_7_days_lte: today_str,
 }),
 (_('This month'), {

Modified: django/trunk/django/contrib/auth/tokens.py
===
--- django/trunk/django/contrib/auth/tokens.py  2011-10-13 19:18:27 UTC (rev 
16977)
+++ django/trunk/django/contrib/auth/tokens.py  2011-10-13 19:23:45 UTC (rev 
16978)
@@ -52,14 +52,13 @@
 # invalid as soon as it is used.
 # We limit the hash to 20 chars to keep URL short
 key_salt = "django.contrib.auth.tokens.PasswordResetTokenGenerator"
-value = unicode(user.id) + \
-user.password + user.last_login.strftime('%Y-%m-%d %H:%M:%S') + \
-unicode(timestamp)
+value = (unicode(user.id) + user.password +
+unicode(user.last_login) + unicode(timestamp))
 hash = salted_hmac(key_salt, value).hexdigest()[::2]
 return "%s-%s" % (ts_b36, hash)
 
 def _num_days(self, dt):
-return (dt - date(2001,1,1)).days
+return (dt - date(2001, 1, 1)).days
 
 def _today(self):
 # Used for mocking in tests

Modified: django/trunk/django/contrib/sitemaps/tests/basic.py
===
--- django/trunk/django/contrib/sitemaps/tests/basic.py 2011-10-13 19:18:27 UTC 
(rev 16977)
+++ django/trunk/django/contrib/sitemaps/tests/basic.py 2011-10-13 19:23:45 UTC 
(rev 16978)
@@ -67,7 +67,7 @@
 http://www.sitemaps.org/schemas/sitemap/0.9";>
 
%s/location/%snever0.5
 
-""" % (self.base_url, date.today().strftime('%Y-%m-%d')))
+""" % (self.base_url, date.today()))
 
 def test_simple_custom_sitemap(self):
 "A simple sitemap can be rendered with a custom template"
@@ -79,7 +79,7 @@
 http://www.sitemaps.org/schemas/sitemap/0.9";>
 
%s/location/%snever0.5
 
-""" % (self.base_url, date.today().strftime('%Y-%m-%d')))
+""" % (self.base_url, date.today()))
 
 @skipUnless(settings.USE_I18N, "Internationalization is not enabled")
 def test_localized_priority(self):
@@ -93,7 +93,7 @@
 # haven't been rendered in localized format
 response = self.client.get('/simple/sitemap.xml')
 self.assertContains(response, '0.5')
-self.assertContains(response, '%s' % 
date.today().strftime('%Y-%m-%d'))
+self.assertContains(response, '%s' % date.today())
 deactivate()
 
 def test_generic_sitemap(self):
@@ -152,7 +152,7 @@
 http://www.sitemaps.org/schemas/sitemap/0.9";>
 
http://testserver/location/%snever0.5
 
-""" % date.today().strftime('%Y-%m-%d'))
+""" % date.today())
 
 @skipUnless("django.contrib.sites" in settings.INSTALLED_APPS, 
"django.contrib.sites app not installed.")
 def test_sitemap_get_urls_no_site_1(self):

Modified: django/trunk/django/db/backends/__init__.py
===
--- django/trunk/django/db/backends/__init__.py 2011-10-13 19:18:27 UTC (rev 
16977)
+++ django/trunk/django/db/backends/__init__.py 2011-10-13 19:23:45 UTC (rev 
16978)
@@ -9,7 +9,6 @@
 from django.db import DEFA

Re: [Django] #16906: Avoid strftime when isoformat can do the job

[Django]

#16906: Avoid strftime when isoformat can do the job
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.3
Component:  Core (Other) |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16978]:
 {{{
 #!CommitTicketReference repository="" revision="16978"
 Fixed #16906 -- Format datetimes with str/unicode instead of strftime
 where possible: it's faster and it works for all dates.

 Also ensured that datetime_safe is used wherever strftime is called on
 dates/datetimes that may be before 1900.
 }}}

-- 
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-updates@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] r16977 - django/trunk/tests/regressiontests/dispatch/tests

[noreply]

Author: Alex
Date: 2011-10-13 12:18:27 -0700 (Thu, 13 Oct 2011)
New Revision: 16977

Modified:
   django/trunk/tests/regressiontests/dispatch/tests/__init__.py
   django/trunk/tests/regressiontests/dispatch/tests/test_dispatcher.py
   django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py
Log:
Fix the dispatch tests on python 2.5

Modified: django/trunk/tests/regressiontests/dispatch/tests/__init__.py
===
--- django/trunk/tests/regressiontests/dispatch/tests/__init__.py   
2011-10-13 18:51:33 UTC (rev 16976)
+++ django/trunk/tests/regressiontests/dispatch/tests/__init__.py   
2011-10-13 19:18:27 UTC (rev 16977)
@@ -4,5 +4,5 @@
 
 from __future__ import absolute_import
 
-from .test_saferef import *
-from .test_dispatcher import *
+from .test_dispatcher import DispatcherTests
+from .test_saferef import SaferefTests

Modified: django/trunk/tests/regressiontests/dispatch/tests/test_dispatcher.py
===
--- django/trunk/tests/regressiontests/dispatch/tests/test_dispatcher.py
2011-10-13 18:51:33 UTC (rev 16976)
+++ django/trunk/tests/regressiontests/dispatch/tests/test_dispatcher.py
2011-10-13 19:18:27 UTC (rev 16977)
@@ -116,9 +116,3 @@
 garbage_collect()
 a_signal.disconnect(receiver_3)
 self._testIsClean(a_signal)
-
-def getSuite():
-return unittest.makeSuite(DispatcherTests,'test')
-
-if __name__ == "__main__":
-unittest.main()

Modified: django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py
===
--- django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py   
2011-10-13 18:51:33 UTC (rev 16976)
+++ django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py   
2011-10-13 19:18:27 UTC (rev 16977)
@@ -13,7 +13,7 @@
 def __call__(self, obj):
 pass
 
-class Tester(unittest.TestCase):
+class SaferefTests(unittest.TestCase):
 def setUp(self):
 ts = []
 ss = []
@@ -47,7 +47,7 @@
 for s in self.ss:
 self.assertTrue(s())
 
-def testShortCircuit (self):
+def testShortCircuit(self):
 """Test that creation short-circuits to reuse existing references"""
 sd = {}
 for s in self.ss:
@@ -60,7 +60,7 @@
 self.assertTrue(sd.has_key(safeRef(t)))
 self.assertTrue(safeRef(t) in sd)
 
-def testRepresentation (self):
+def testRepresentation(self):
 """Test that the reference object's representation works
 
 XXX Doesn't currently check the results, just that no error
@@ -70,10 +70,4 @@
 
 def _closure(self, ref):
 """Dumb utility mechanism to increment deletion counter"""
-self.closureCount +=1
-
-def getSuite():
-return unittest.makeSuite(Tester,'test')
-
-if __name__ == "__main__":
-unittest.main()
+self.closureCount +=1
\ No newline at end of file

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #16969: Avoid selecting production database prior to test database setup/teardown

[Django]

#16969: Avoid selecting production database prior to test database 
setup/teardown
--+
 Reporter:  andreas_pelme |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 Under PostgreSQL, is it guaranteed that all users can always connect to
 the `postgres` database? Otherwise, the patch is incorrect.

-- 
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-updates@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] #16969: Avoid selecting production database prior to test database setup/teardown

[Django]

#16969: Avoid selecting production database prior to test database 
setup/teardown
--+
 Reporter:  andreas_pelme |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 The test suite runs under Oracle with the patch applied.

-- 
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-updates@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] #15372: manage.py adds to sys.path and forcibly imports the parent dir of the settings module

[Django]

#15372: manage.py adds to sys.path and forcibly imports the parent dir of the
settings module
-+-
 Reporter:  Jorge Vargas |Owner:  russellm
 |   Status:  closed
 Type:  Bug  |  Version:  SVN
Component:  Core (Other) |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Jorge Vargas ):

 This looks like a great solution, Thanks Carl!

-- 
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-updates@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] #16969: Avoid selecting production database prior to test database setup/teardown

[Django]

#16969: Avoid selecting production database prior to test database 
setup/teardown
--+
 Reporter:  andreas_pelme |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

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


Comment:

 If its possible to avoid connecting to the production DB at all for test
 runs, I think we should do this. Needs someone with Oracle to test the
 behavior there.

-- 
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-updates@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] #17046: User.objects.create_user() allows empty usernames

[Django]

#17046: User.objects.create_user() allows empty usernames
--+
 Reporter:  honza |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 This code will work:

 {{{#!python
 User.objects.create_user(username='', email='t...@test.com',
 password='password')
 }}}

 It should raise some kind of exception.

 I searched for this in the tracker and didn't find any references. I'm
 happy to work on this given some direction from the core.

-- 
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-updates@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] #14720: Settings imported twice as separate modules when manage.py is used

[Django]

#14720: Settings imported twice as separate modules when manage.py is used
-+-
 Reporter:  zimnyx   |Owner:  bretth
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Other) |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 This was indeed fixed by r16964 - didn't realize there was a ticket open
 for 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-updates@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] #17045: Provide the equivalent of pgettext in the translation template tags (was: trans tag and msgctxt)

[Django]

#17045: Provide the equivalent of pgettext in the translation template tags
--+--
 Reporter:  herve |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Translations  |  Version:  1.3
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by aaugustin):

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


Old description:

> Using pgettext you can specify a contextual marker:
>
> https://docs.djangoproject.com/en/1.3/topics/i18n/internationalization
> /#contextual-markers
>
> But there is nothing in templates to call such translations.
>
> Proposal:
>
> {% trans "May" "month name" %}
>
> {% blocktrans msgctxt="month name" %}May{% endblocktrans %}

New description:

 Using pgettext you can specify a contextual marker:

 https://docs.djangoproject.com/en/1.3/topics/i18n/internationalization
 /#contextual-markers

 But there is nothing in templates to call such translations.

 Proposal:
 {{{
 {% trans "May" "month name" %}
 }}}
 {{{
 {% blocktrans msgctxt="month name" %}May{% endblocktrans %}
 }}}

--

Comment:

 This is a duplicate of #14806. And yes, it's annoying.

-- 
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-updates@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] #17045: trans tag and msgctxt

[Django]

#17045: trans tag and msgctxt
--+
 Reporter:  herve |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Translations  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Using pgettext you can specify a contextual marker:

 https://docs.djangoproject.com/en/1.3/topics/i18n/internationalization
 /#contextual-markers

 But there is nothing in templates to call such translations.

 Proposal:

 {% trans "May" "month name" %}

 {% blocktrans msgctxt="month name" %}May{% endblocktrans %}

-- 
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-updates@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] r16974 - in django/trunk: django/views/generic tests/regressiontests/generic_views

[noreply]

Author: julien
Date: 2011-10-13 06:38:38 -0700 (Thu, 13 Oct 2011)
New Revision: 16974

Modified:
   django/trunk/django/views/generic/dates.py
   django/trunk/tests/regressiontests/generic_views/dates.py
   django/trunk/tests/regressiontests/generic_views/urls.py
   django/trunk/tests/regressiontests/generic_views/views.py
Log:
Fixed #16918 -- Ensured that custom querysets are used when provided to 
`BaseDateDetailView.get_object()`. Thanks to mitar for the report, to koenb for 
the patch and to Preston Holmes for the review.

Modified: django/trunk/django/views/generic/dates.py
===
--- django/trunk/django/views/generic/dates.py  2011-10-13 12:53:02 UTC (rev 
16973)
+++ django/trunk/django/views/generic/dates.py  2011-10-13 13:38:38 UTC (rev 
16974)
@@ -459,7 +459,8 @@
  month, self.get_month_format(),
  day, self.get_day_format())
 
-qs = self.get_queryset()
+# Use a custom queryset if provided
+qs = queryset or self.get_queryset()
 
 if not self.get_allow_future() and date > datetime.date.today():
 raise Http404(_(u"Future %(verbose_name_plural)s not available 
because %(class_name)s.allow_future is False.") % {

Modified: django/trunk/tests/regressiontests/generic_views/dates.py
===
--- django/trunk/tests/regressiontests/generic_views/dates.py   2011-10-13 
12:53:02 UTC (rev 16973)
+++ django/trunk/tests/regressiontests/generic_views/dates.py   2011-10-13 
13:38:38 UTC (rev 16974)
@@ -412,3 +412,19 @@
 def test_invalid_url(self):
 self.assertRaises(AttributeError, self.client.get, 
"/dates/books/2008/oct/01/nopk/")
 
+def test_get_object_custom_queryset(self):
+"""
+Ensure that custom querysets are used when provided to
+BaseDateDetailView.get_object()
+Refs #16918.
+"""
+res = self.client.get(
+'/dates/books/get_object_custom_queryset/2006/may/01/2/')
+self.assertEqual(res.status_code, 200)
+self.assertEqual(res.context['object'], Book.objects.get(pk=2))
+self.assertEqual(res.context['book'], Book.objects.get(pk=2))
+self.assertTemplateUsed(res, 'generic_views/book_detail.html')
+
+res = self.client.get(
+'/dates/books/get_object_custom_queryset/2008/oct/01/1/')
+self.assertEqual(res.status_code, 404)

Modified: django/trunk/tests/regressiontests/generic_views/urls.py
===
--- django/trunk/tests/regressiontests/generic_views/urls.py2011-10-13 
12:53:02 UTC (rev 16973)
+++ django/trunk/tests/regressiontests/generic_views/urls.py2011-10-13 
13:38:38 UTC (rev 16974)
@@ -216,6 +216,9 @@
 
(r'^dates/books/(?P\d{4})/(?P[a-z]{3})/(?P\d{1,2})/byslug/(?P[\w-]+)/$',
 views.BookDetail.as_view()),
 
+
(r'^dates/books/get_object_custom_queryset/(?P\d{4})/(?P[a-z]{3})/(?P\d{1,2})/(?P\d+)/$',
+views.BookDetailGetObjectCustomQueryset.as_view()),
+
 # Useful for testing redirects
 (r'^accounts/login/$',  'django.contrib.auth.views.login')
 )

Modified: django/trunk/tests/regressiontests/generic_views/views.py
===
--- django/trunk/tests/regressiontests/generic_views/views.py   2011-10-13 
12:53:02 UTC (rev 16973)
+++ django/trunk/tests/regressiontests/generic_views/views.py   2011-10-13 
13:38:38 UTC (rev 16974)
@@ -177,3 +177,8 @@
 class AuthorGetQuerySetFormView(generic.edit.ModelFormMixin):
 def get_queryset(self):
 return Author.objects.all()
+
+class BookDetailGetObjectCustomQueryset(BookDetail):
+def get_object(self, queryset=None):
+return super(BookDetailGetObjectCustomQueryset,self).get_object(
+queryset=Book.objects.filter(pk=2))

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #16918: BaseDateDetailView's get_object ignores queryset argument

[Django]

#16918: BaseDateDetailView's get_object ignores queryset argument
-+-
 Reporter:  mitar|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16974]:
 {{{
 #!CommitTicketReference repository="" revision="16974"
 Fixed #16918 -- Ensured that custom querysets are used when provided to
 `BaseDateDetailView.get_object()`. Thanks to mitar for the report, to
 koenb for the patch and to Preston Holmes for the review.
 }}}

-- 
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-updates@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] r16973 - in django/trunk/tests: modeltests/mutually_referential regressiontests/admin_custom_urls regressiontests/dispatch/tests regressiontests/forms/tests regressiontests/text regressio

[noreply]

Author: Alex
Date: 2011-10-13 05:53:02 -0700 (Thu, 13 Oct 2011)
New Revision: 16973

Modified:
   django/trunk/tests/modeltests/mutually_referential/models.py
   django/trunk/tests/regressiontests/admin_custom_urls/urls.py
   django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py
   django/trunk/tests/regressiontests/forms/tests/error_messages.py
   django/trunk/tests/regressiontests/text/tests.py
   django/trunk/tests/regressiontests/utils/datastructures.py
Log:
Remove a handful of `import *` from the tests.

Modified: django/trunk/tests/modeltests/mutually_referential/models.py
===
--- django/trunk/tests/modeltests/mutually_referential/models.py
2011-10-13 12:23:58 UTC (rev 16972)
+++ django/trunk/tests/modeltests/mutually_referential/models.py
2011-10-13 12:53:02 UTC (rev 16973)
@@ -4,16 +4,17 @@
 Strings can be used instead of model literals to set up "lazy" relations.
 """
 
-from django.db.models import *
+from django.db import models
 
-class Parent(Model):
-name = CharField(max_length=100)
 
+class Parent(models.Model):
+name = models.CharField(max_length=100)
+
 # Use a simple string for forward declarations.
-bestchild = ForeignKey("Child", null=True, related_name="favoured_by")
+bestchild = models.ForeignKey("Child", null=True, 
related_name="favoured_by")
 
-class Child(Model):
-name = CharField(max_length=100)
+class Child(models.Model):
+name = models.CharField(max_length=100)
 
 # You can also explicitally specify the related app.
-parent = ForeignKey("mutually_referential.Parent")
+parent = models.ForeignKey("mutually_referential.Parent")

Modified: django/trunk/tests/regressiontests/admin_custom_urls/urls.py
===
--- django/trunk/tests/regressiontests/admin_custom_urls/urls.py
2011-10-13 12:23:58 UTC (rev 16972)
+++ django/trunk/tests/regressiontests/admin_custom_urls/urls.py
2011-10-13 12:53:02 UTC (rev 16973)
@@ -1,6 +1,7 @@
-from django.conf.urls.defaults import *
+from django.conf.urls import patterns, include
 from django.contrib import admin
 
+
 urlpatterns = patterns('',
 (r'^admin/', include(admin.site.urls)),
 )

Modified: django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py
===
--- django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py   
2011-10-13 12:23:58 UTC (rev 16972)
+++ django/trunk/tests/regressiontests/dispatch/tests/test_saferef.py   
2011-10-13 12:53:02 UTC (rev 16973)
@@ -1,7 +1,7 @@
-from django.dispatch.saferef import *
-
+from django.dispatch.saferef import safeRef
 from django.utils import unittest
 
+
 class Test1(object):
 def x(self):
 pass
@@ -32,21 +32,21 @@
 self.ts = ts
 self.ss = ss
 self.closureCount = 0
-
+
 def tearDown(self):
 del self.ts
 del self.ss
-
+
 def testIn(self):
 """Test the "in" operator for safe references (cmp)"""
 for t in self.ts[:50]:
 self.assertTrue(safeRef(t.x) in self.ss)
-
+
 def testValid(self):
 """Test that the references are valid (return instance methods)"""
 for s in self.ss:
 self.assertTrue(s())
-
+
 def testShortCircuit (self):
 """Test that creation short-circuits to reuse existing references"""
 sd = {}
@@ -59,15 +59,15 @@
 else:
 self.assertTrue(sd.has_key(safeRef(t)))
 self.assertTrue(safeRef(t) in sd)
-
+
 def testRepresentation (self):
 """Test that the reference object's representation works
-
+
 XXX Doesn't currently check the results, just that no error
 is raised
 """
 repr(self.ss[-1])
-
+
 def _closure(self, ref):
 """Dumb utility mechanism to increment deletion counter"""
 self.closureCount +=1

Modified: django/trunk/tests/regressiontests/forms/tests/error_messages.py
===
--- django/trunk/tests/regressiontests/forms/tests/error_messages.py
2011-10-13 12:23:58 UTC (rev 16972)
+++ django/trunk/tests/regressiontests/forms/tests/error_messages.py
2011-10-13 12:53:02 UTC (rev 16973)
@@ -4,8 +4,10 @@
 from django.test import TestCase
 from django.utils.safestring import mark_safe
 from django.utils import unittest
+
 from regressiontests.forms.tests.fields import verify_exists_urls
 
+
 class AssertFormErrorsMixin(object):
 def assertFormErrors(self, expected, the_callable, *args, **kwargs):
 try:
@@ -14,7 +16,6 @@
 except ValidationError, e:
 self.assertEqual(e.messages, expected)
 
-
 class FormsErrorMessagesTestCase(unittest.TestCase, AssertFormErrorsMixin):
 def test_charfield(self):
 e = {

Modified: django/trunk/

Re: [Django] #7609: Document that PositiveIntegerField and co have a misleading name

[Django]

#7609: Document that PositiveIntegerField and co have a misleading name
-+-
 Reporter:  Gergely Kontra   |Owner:
  |  paulcollins
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  name convention, | Triage Stage:  Ready for
  rename |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by julien):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16972]:
 {{{
 #!CommitTicketReference repository="" revision="16972"
 Fixed #7609 -- Noted in the model fields reference documentation that
 `PositiveIntegerField` accepts the value 0 for backwards-compatibility
 reasons. Thanks to everyone involved in the resolution of this issue,
 including Paul Collins for the patch.
 }}}

-- 
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-updates@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] r16972 - django/trunk/docs/ref/models

[noreply]

Author: julien
Date: 2011-10-13 05:23:58 -0700 (Thu, 13 Oct 2011)
New Revision: 16972

Modified:
   django/trunk/docs/ref/models/fields.txt
Log:
Fixed #7609 -- Noted in the model fields reference documentation that 
`PositiveIntegerField` accepts the value 0 for backwards-compatibility reasons. 
Thanks to everyone involved in the resolution of this issue, including Paul 
Collins for the patch.

Modified: django/trunk/docs/ref/models/fields.txt
===
--- django/trunk/docs/ref/models/fields.txt 2011-10-13 11:53:59 UTC (rev 
16971)
+++ django/trunk/docs/ref/models/fields.txt 2011-10-13 12:23:58 UTC (rev 
16972)
@@ -805,7 +805,8 @@
 
 .. class:: PositiveIntegerField([**options])
 
-Like an :class:`IntegerField`, but must be positive.
+Like an :class:`IntegerField`, but must be either positive or zero (`0`).
+The value `0` is accepted for backward compatibility reasons.
 
 ``PositiveSmallIntegerField``
 -

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #11670: Model fields named 'year', 'month', 'gt', 'lt' etc. get mistaken for lookup types in lookups across relations

[Django]

#11670: Model fields named 'year', 'month', 'gt', 'lt' etc. get mistaken for 
lookup
types in lookups across relations
-+-
 Reporter:  andy@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * needs_better_patch:  0 => 1


Comment:

 Some notes:
   - TYPO: Lookups on non-existants fields are ok, since they're ignored
   - Shouldn't the cache be cleared in add_field like the other field
 caches?
   - Is it absolutely necessary to pass in the query into
 resolve_lookup_path, it is only used in:
 {{{
 field_name not in query.query_terms and
 field_name not in query.aggregate_select.keys() and
 field_name not in query.aggregates.keys() and
 LOOKUP_SEP.join(parts) not in query.aggregates.keys()
 }}}
 It would be IMHO better to pass in two sets, one containing the first
 three lines unioned, and the other the query.aggregates.keys(). Even
 better would be to move some of this logic into query.py. One idea is just
 to ignore the whole `FieldDoesNotExist` and let the caller work out what
 the result should be. So if you resolve 'foo`__`bar_id', you would only
 resolve the foo part and let the caller figure out what to do with the
 bar_id part. There is also a related bug here: the cache key is the passed
 in path, but the result which is cached depends also on the query and
 allow_explicit_fk, so if first called with 'foo`__`bar_id', True, we would
 cache the wrong result for the call 'foo`__`bar_id', False.

 Otherwise the patch looks good to me. This is a big cleanup to lookup path
 handling in my opinion.

-- 
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-updates@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] #12467: More helpful error message when loading fixture with invalid date

[Django]

#12467: More helpful error message when loading fixture with invalid date
--+
 Reporter:  knutin|Owner:  raulcd
 Type:  New feature   |   Status:  closed
Component:  Core (Serialization)  |  Version:  SVN
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by julien):

 In [16971]:
 {{{
 #!CommitTicketReference repository="" revision="16971"
 Fixed a couple of `assert` syntax warnings mistakingly introduced in
 r16966 and added some tests to prevent future regressions. Thanks to Anssi
 Kääriäinen for the report.
 Refs #12467.
 }}}

-- 
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-updates@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] r16971 - in django/trunk: django/db/models/fields tests/modeltests/validation

[noreply]

Author: julien
Date: 2011-10-13 04:53:59 -0700 (Thu, 13 Oct 2011)
New Revision: 16971

Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/tests/modeltests/validation/models.py
   django/trunk/tests/modeltests/validation/test_error_messages.py
Log:
Fixed a couple of `assert` syntax warnings mistakingly introduced in r16966 and 
added some tests to prevent future regressions. Thanks to Anssi 
Ka?\204?\136a?\204?\136ria?\204?\136inen for the report.
Refs #12467.

Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2011-10-13 11:21:42 UTC 
(rev 16970)
+++ django/trunk/django/db/models/fields/__init__.py2011-10-13 11:53:59 UTC 
(rev 16971)
@@ -510,8 +510,8 @@
 'invalid': _(u"'%s' value must be an integer."),
 }
 def __init__(self, *args, **kwargs):
-assert (kwargs.get('primary_key', False) is True,
-"%ss must have primary_key=True." % self.__class__.__name__)
+assert kwargs.get('primary_key', False) is True, \
+   "%ss must have primary_key=True." % self.__class__.__name__
 kwargs['blank'] = True
 Field.__init__(self, *args, **kwargs)
 
@@ -536,8 +536,8 @@
 return int(value)
 
 def contribute_to_class(self, cls, name):
-assert (not cls._meta.has_auto_field,
-"A model can't have more than one AutoField.")
+assert not cls._meta.has_auto_field, \
+   "A model can't have more than one AutoField."
 super(AutoField, self).contribute_to_class(cls, name)
 cls._meta.has_auto_field = True
 cls._meta.auto_field = self

Modified: django/trunk/tests/modeltests/validation/models.py
===
--- django/trunk/tests/modeltests/validation/models.py  2011-10-13 11:21:42 UTC 
(rev 16970)
+++ django/trunk/tests/modeltests/validation/models.py  2011-10-13 11:53:59 UTC 
(rev 16971)
@@ -90,3 +90,13 @@
 
 class GenericIPAddrUnpackUniqueTest(models.Model):
 generic_v4unpack_ip = models.GenericIPAddressField(blank=True, 
unique=True, unpack_ipv4=True)
+
+
+try:
+# A model can't have multiple AutoFields
+# Refs #12467.
+class MultipleAutoFields(models.Model):
+auto1 = models.AutoField(primary_key=True)
+auto2 = models.AutoField(primary_key=True)
+except AssertionError, e:
+assert e.message == u"A model can't have more than one AutoField."
\ No newline at end of file

Modified: django/trunk/tests/modeltests/validation/test_error_messages.py
===
--- django/trunk/tests/modeltests/validation/test_error_messages.py 
2011-10-13 11:21:42 UTC (rev 16970)
+++ django/trunk/tests/modeltests/validation/test_error_messages.py 
2011-10-13 11:53:59 UTC (rev 16971)
@@ -12,6 +12,12 @@
 f.clean('foo', None)
 except ValidationError, e:
 self.assertEqual(e.messages, [u"'foo' value must be an integer."])
+# primary_key must be True. Refs #12467.
+self.assertRaises(AssertionError, models.AutoField, 'primary_key', 
False)
+try:
+models.AutoField(primary_key=False)
+except AssertionError, e:
+self.assertEqual(e.message, u"AutoFields must have 
primary_key=True.")
 
 def test_integer_field_raises_error_message(self):
 f = models.IntegerField()

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] r16970 - django/trunk/docs/intro

[noreply]

Author: ramiro
Date: 2011-10-13 04:21:42 -0700 (Thu, 13 Oct 2011)
New Revision: 16970

Modified:
   django/trunk/docs/intro/tutorial02.txt
Log:
Added note to tutorial part #2 about possible mismatch with the Django version 
being used regarding changes in location of django.conf.urls[.defaults] 
symbols. Thansk Carl for the suggestion.

Modified: django/trunk/docs/intro/tutorial02.txt
===
--- django/trunk/docs/intro/tutorial02.txt  2011-10-13 11:00:08 UTC (rev 
16969)
+++ django/trunk/docs/intro/tutorial02.txt  2011-10-13 11:21:42 UTC (rev 
16970)
@@ -77,6 +77,19 @@
 .. image:: _images/admin01.png
:alt: Django admin login screen
 
+.. admonition:: Doesn't match what you see?
+
+If at this point, instead of the above login page, you get an error
+page reporting something like::
+
+ImportError at /admin/
+cannot import name patterns
+...
+
+then you're probably using a version of Django that doesn't match this
+tutorial version. You'll want to either switch to the older tutorial or the
+newer Django version.
+
 Enter the admin site
 
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #12467: More helpful error message when loading fixture with invalid date

[Django]

#12467: More helpful error message when loading fixture with invalid date
--+
 Reporter:  knutin|Owner:  raulcd
 Type:  New feature   |   Status:  closed
Component:  Core (Serialization)  |  Version:  SVN
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by julien):

 Well spotted. This is weird, I didn't see those warnings when running the
 tests. I'll fix that in a minute. Thanks!

-- 
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-updates@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] #12467: More helpful error message when loading fixture with invalid date

[Django]

#12467: More helpful error message when loading fixture with invalid date
--+
 Reporter:  knutin|Owner:  raulcd
 Type:  New feature   |   Status:  closed
Component:  Core (Serialization)  |  Version:  SVN
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by akaariai):

 The commit made a couple of always True asserts:

 {{{
 /home/akaj/Django/django_test/django/db/models/fields/__init__.py:513:
 SyntaxWarning: assertion is always true, perhaps remove parentheses?
   assert (kwargs.get('primary_key', False) is True,
 /home/akaj/Django/django_test/django/db/models/fields/__init__.py:539:
 SyntaxWarning: assertion is always true, perhaps remove parentheses?

 }}}

-- 
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-updates@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] r16969 - django/trunk/docs/topics/i18n

[noreply]

Author: ramiro
Date: 2011-10-13 04:00:08 -0700 (Thu, 13 Oct 2011)
New Revision: 16969

Modified:
   django/trunk/docs/topics/i18n/localization.txt
Log:
Removed a couple of notes associated with deprecated utilities from the 
localization document to unclutter it a bit.

Modified: django/trunk/docs/topics/i18n/localization.txt
===
--- django/trunk/docs/topics/i18n/localization.txt  2011-10-13 10:09:17 UTC 
(rev 16968)
+++ django/trunk/docs/topics/i18n/localization.txt  2011-10-13 11:00:08 UTC 
(rev 16969)
@@ -49,11 +49,6 @@
 Django comes with a tool, ``django-admin.py makemessages``, that automates the
 creation and upkeep of these files.
 
-.. admonition:: A note to Django veterans
-
-The old tool ``bin/make-messages.py`` has been moved to the command
-``django-admin.py makemessages`` to provide consistency throughout Django.
-
 .. admonition:: Gettext utilities
 
 The ``makemessages`` command (and ``compilemessages`` discussed later) use
@@ -179,12 +174,6 @@
 
 That's it. Your translations are ready for use.
 
-.. admonition:: A note to Django veterans
-
-The old tool ``bin/compile-messages.py`` has been moved to the command
-``django-admin.py compilemessages`` to provide consistency throughout
-Django.
-
 .. admonition:: Working on Windows?
 
If you're using Windows and need to install the GNU gettext utilities so
@@ -202,9 +191,11 @@
 Creating message files from JavaScript source code
 ==
 
-You create and update the message files the same way as the other Django 
message
-files -- with the ``django-admin.py makemessages`` tool. The only difference is
-you need to provide a ``-d djangojs`` parameter, like this::
+You create and update the message files the same way as the other Django
+message files -- with the ``django-admin.py makemessages`` tool. The only
+difference is you need to explicitly specify what in gettext parlance is known
+as a domain in this case the ``djangojs`` domain, by providing a ``-d 
djangojs``
+parameter, like this::
 
 django-admin.py makemessages -d djangojs -l de
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #11707: limit_choices_to on a ForeignKey can render duplicate options in formfield

[Django]

#11707: limit_choices_to on a ForeignKey can render duplicate options in 
formfield
-+-
 Reporter:  Chris.Wesseling@…|Owner:
 Type:  Bug  |  charstring
Component:  Forms|   Status:  new
 Severity:  Normal   |  Version:  SVN
 Keywords:  ForeingKey   |   Resolution:
  limit_choices_to, dceu2011 | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charstring):

 DISTINCT is just a special GROUP BY...

 So an empty `.annotate()` does the trick too, since it groups by the pk.
 And the DBMS should by definition be able to compare pk's.
 I'll try to put up a patch tonight.

-- 
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-updates@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] r16968 - django/trunk/django/contrib/admin/static/admin/css

[noreply]

Author: julien
Date: 2011-10-13 03:09:17 -0700 (Thu, 13 Oct 2011)
New Revision: 16968

Modified:
   django/trunk/django/contrib/admin/static/admin/css/base.css
   django/trunk/django/contrib/admin/static/admin/css/changelists.css
Log:
Fixed a padding issue in admin tabular inline headers.

Modified: django/trunk/django/contrib/admin/static/admin/css/base.css
===
--- django/trunk/django/contrib/admin/static/admin/css/base.css 2011-10-13 
09:20:10 UTC (rev 16967)
+++ django/trunk/django/contrib/admin/static/admin/css/base.css 2011-10-13 
10:09:17 UTC (rev 16968)
@@ -310,7 +310,7 @@
 /* SORTABLE TABLES */
 
 thead th {
-padding: 0;
+padding: 2px 5px;
 line-height: normal;
 }
 

Modified: django/trunk/django/contrib/admin/static/admin/css/changelists.css
===
--- django/trunk/django/contrib/admin/static/admin/css/changelists.css  
2011-10-13 09:20:10 UTC (rev 16967)
+++ django/trunk/django/contrib/admin/static/admin/css/changelists.css  
2011-10-13 10:09:17 UTC (rev 16968)
@@ -51,6 +51,7 @@
 /* CHANGELIST TABLES */
 
 #changelist table thead th {
+padding: 0;
 white-space: nowrap;
 vertical-align: middle;
 }

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #16776: jQuery.noConflict(false) in jquery.init.js leaks the admin jQuery into the global namespace

[Django]

#16776: jQuery.noConflict(false) in jquery.init.js leaks the admin jQuery into 
the
global namespace
---+
 Reporter:  anonymous  |Owner:  julien
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:  fixed
 Keywords:  jQuery admin   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by julien):

 * status:  new => closed
 * owner:   => julien
 * resolution:   => fixed


Comment:

 In [16967]:
 {{{
 #!CommitTicketReference repository="" revision="16967"
 Fixed #16776 -- Fixed a regression introduced in r16415 which caused
 Django's embedded jQuery to overwrite any pre-existing values of
 `window.jQuery` in the global namespace. Many thanks to Rob Hudson, Jannis
 Leidel and "anonymous" for the help resolving this issue.
 }}}

-- 
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-updates@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] r16967 - in django/trunk: django/contrib/admin/static/admin/js docs/ref/contrib/admin

[noreply]

Author: julien
Date: 2011-10-13 02:20:10 -0700 (Thu, 13 Oct 2011)
New Revision: 16967

Modified:
   django/trunk/django/contrib/admin/static/admin/js/jquery.init.js
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Fixed #16776 -- Fixed a regression introduced in r16415 which caused Django's 
embedded jQuery to overwrite any pre-existing values of `window.jQuery` in the 
global namespace. Many thanks to Rob Hudson, Jannis Leidel and "anonymous" for 
the help resolving this issue.

Modified: django/trunk/django/contrib/admin/static/admin/js/jquery.init.js
===
--- django/trunk/django/contrib/admin/static/admin/js/jquery.init.js
2011-10-13 08:11:00 UTC (rev 16966)
+++ django/trunk/django/contrib/admin/static/admin/js/jquery.init.js
2011-10-13 09:20:10 UTC (rev 16967)
@@ -1,4 +1,8 @@
-// Puts the included jQuery into our own namespace
+/* Puts the included jQuery into our own namespace using noConflict and passing
+ * it 'true'. This ensures that the included jQuery doesn't pollute the global
+ * namespace (i.e. this preserves pre-existing values for both window.$ and
+ * window.jQuery).
+ */
 var django = {
-"jQuery": jQuery.noConflict()
+"jQuery": jQuery.noConflict(true)
 };

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2011-10-13 08:11:00 UTC 
(rev 16966)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2011-10-13 09:20:10 UTC 
(rev 16967)
@@ -1289,11 +1289,15 @@
 definitions on forms `.
 
 Django admin Javascript makes use of the `jQuery`_ library. To avoid
-conflict with user scripts, Django's jQuery is namespaced as
-``django.jQuery``. If you want to use jQuery in your own admin
-JavaScript without including a second copy, you can use the
-``django.jQuery`` object on changelist and add/edit views.
+conflicts with user-supplied scripts or libraries, Django's jQuery is
+namespaced as ``django.jQuery``. If you want to use jQuery in your own admin
+JavaScript without including a second copy, you can use the ``django.jQuery``
+object on changelist and add/edit views.
 
+If you require the jQuery library to be in the global namespace, for example
+when using third-party jQuery plugins, or need a newer version of jQuery, you
+will have to include your own copy of jQuery.
+
 .. _jQuery: http://jquery.com
 
 Adding custom validation to the admin

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@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] #14720: Settings imported twice as separate modules when manage.py is used

[Django]

#14720: Settings imported twice as separate modules when manage.py is used
-+-
 Reporter:  zimnyx   |Owner:  bretth
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I suspect that this might be resolved now after changeset:16964. Just need
 someone confirmation to close the ticket.

-- 
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-updates@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] #12467: More helpful error message when loading fixture with invalid date

[Django]

#12467: More helpful error message when loading fixture with invalid date
--+
 Reporter:  knutin|Owner:  raulcd
 Type:  New feature   |   Status:  closed
Component:  Core (Serialization)  |  Version:  SVN
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by julien):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [16966]:
 {{{
 #!CommitTicketReference repository="" revision="16966"
 Fixed #12467 -- Made the model data validation for `DateField` and
 `DateTimeField` more useful by actually telling what was the value that
 failed. Also did a bit of PEP8 cleanup in the area. Thanks to knutin for
 the report, to raulcd for the initial patch and to charettes for the
 review.
 }}}

-- 
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-updates@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] r16966 - in django/trunk: django/db/models/fields tests/modeltests/validation

[noreply]

Author: julien
Date: 2011-10-13 01:11:00 -0700 (Thu, 13 Oct 2011)
New Revision: 16966

Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/tests/modeltests/validation/test_error_messages.py
   django/trunk/tests/modeltests/validation/tests.py
Log:
Fixed #12467 -- Made the model data validation for `DateField` and 
`DateTimeField` more useful by actually telling what was the value that failed. 
Also did a bit of PEP8 cleanup in the area. Thanks to knutin for the report, to 
raulcd for the initial patch and to charettes for the review.

Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2011-10-13 06:41:40 UTC 
(rev 16965)
+++ django/trunk/django/db/models/fields/__init__.py2011-10-13 08:11:00 UTC 
(rev 16966)
@@ -22,7 +22,8 @@
 class NOT_PROVIDED:
 pass
 
-# The values to use for "blank" in SelectFields. Will be appended to the start 
of most "choices" lists.
+# The values to use for "blank" in SelectFields. Will be appended to the start
+# of most "choices" lists.
 BLANK_CHOICE_DASH = [("", "-")]
 BLANK_CHOICE_NONE = [("", "None")]
 
@@ -61,7 +62,8 @@
 'invalid_choice': _(u'Value %r is not a valid choice.'),
 'null': _(u'This field cannot be null.'),
 'blank': _(u'This field cannot be blank.'),
-'unique': _(u'%(model_name)s with this %(field_label)s already 
exists.'),
+'unique': _(u'%(model_name)s with this %(field_label)s '
+u'already exists.'),
 }
 
 # Generic field type description, usually overriden by subclasses
@@ -85,13 +87,15 @@
 self.blank, self.null = blank, null
 # Oracle treats the empty string ('') as null, so coerce the null
 # option whenever '' is a possible value.
-if self.empty_strings_allowed and 
connection.features.interprets_empty_strings_as_nulls:
+if (self.empty_strings_allowed and
+connection.features.interprets_empty_strings_as_nulls):
 self.null = True
 self.rel = rel
 self.default = default
 self.editable = editable
 self.serialize = serialize
-self.unique_for_date, self.unique_for_month = unique_for_date, 
unique_for_month
+self.unique_for_date, self.unique_for_month = (unique_for_date,
+   unique_for_month)
 self.unique_for_year = unique_for_year
 self._choices = choices or []
 self.help_text = help_text
@@ -99,7 +103,8 @@
 self.db_tablespace = db_tablespace or settings.DEFAULT_INDEX_TABLESPACE
 self.auto_created = auto_created
 
-# Set db_index to True if the field has a relationship and doesn't 
explicitly set db_index.
+# Set db_index to True if the field has a relationship and doesn't
+# explicitly set db_index.
 self.db_index = db_index
 
 # Adjust the appropriate creation counter, and save our local copy.
@@ -169,13 +174,15 @@
 if self._choices and value:
 for option_key, option_value in self.choices:
 if isinstance(option_value, (list, tuple)):
-# This is an optgroup, so look inside the group for 
options.
+# This is an optgroup, so look inside the group for
+# options.
 for optgroup_key, optgroup_value in option_value:
 if value == optgroup_key:
 return
 elif value == option_key:
 return
-raise 
exceptions.ValidationError(self.error_messages['invalid_choice'] % value)
+raise exceptions.ValidationError(
+self.error_messages['invalid_choice'] % value)
 
 if value is None and not self.null:
 raise exceptions.ValidationError(self.error_messages['null'])
@@ -185,9 +192,9 @@
 
 def clean(self, value, model_instance):
 """
-Convert the value's type and run validation. Validation errors from 
to_python
-and validate are propagated. The correct value is returned if no error 
is
-raised.
+Convert the value's type and run validation. Validation errors
+from to_python and validate are propagated. The correct value is
+returned if no error is raised.
 """
 value = self.to_python(value)
 self.validate(value, model_instance)
@@ -205,9 +212,9 @@
 #
 # A Field class can implement the get_internal_type() method to specify
 # which *preexisting* Django Field class it's most similar to -- i.e.,
-# a custom field might be represented by a TEXT column type, which is 
the
-# same as the TextField Django field type, which means the custom 
field's
-# get_internal_type() returns 'TextField'.
+# a custom field might be r

Re: [Django] #9475: add(), create(), etc. should be supported by intermedite ManyToMany model with extra attributes if extra fields can be calculated

[Django]

#9475: add(), create(), etc. should be supported by intermedite ManyToMany model
with extra attributes if extra fields can be calculated
-+-
 Reporter:  omat@…   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by robin):

 * cc: robinchew@… (added)
 * ui_ux:   => 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-updates@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] #17001: Allow usage of custom querysets in prefetch_related

[Django]

#17001: Allow usage of custom querysets in prefetch_related
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  prefetch_related |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akaariai):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 1


Comment:

 Ok, I think I have a ready patch for this. There are some TODO comments
 still there (a part of them are personal TODOs, some are real TODOs). And
 this still needs documentation.

 About the documentation, I don't know if we should mention that it is
 possible to chain prefetches in this manner:
 {{{
 qs = SomeModel.objects.prefetch_related(
R('rel_model', qs=RelModel.objects.order_by('-pk'), to_attr='foo_lst'),
R('foo_lst__another_model', qs=AnotModel.objects.order_by('-pk'),
 to_attr='anot_lst')
 )
 }}}

 The problem is that it is really, really, easy to do this instead:
 {{{
 qs = SomeModel.objects.prefetch_related(
R('rel_model', qs=RelModel.objects.order_by('-pk'), to_attr='foo_lst'),
R('ref_model__another_model', qs=AnotModel.objects.order_by('-pk'),
 to_attr='anot_lst')
 )
 }}}

 Note that the lookup path in the second R-object isn't referring to
 foo_lst, but instead ref_model, so we will fetch the ref_models another
 time. I would even go so far as to explicitly prohibit the
 foo_lst`__`another_model usage, as it is confusing as hell.

 Chaining prefetches can be done by using custom querysets which have
 prefetches. The only problem is that if you get a queryset which already
 has prefetches, you can't chain to the existing ones. One idea is to have
 a 'name' and 'chain_to' kwargs for R objects, and then you could chain by
 the name.

 My suggestion is that lets leave this for 1.5. I would explicitly prohibit
 the foo_lst`__`another_model way of chaining. It can be resurrected if
 need be. Then there is still the usual naming issues.

-- 
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-updates@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.