[Django] #14761: URL resolving / reversing design doesn't allow alternate specs

[Django]

#14761: URL resolving / reversing design doesn't allow alternate specs
-+--
 Reporter:  samuel337|   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Core framework   | Version:  SVN   
 Keywords:  url resolve reverse  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 Django's URL resolution system is currently based on regexps and is
 represented by the RegexURLPattern class. There are cases where it would
 be preferable to subclass this and allow alternate ways of specifying URL
 patterns that ultimately compile down to regexps.

 Right now, this works for URL resolving as during resolution, the resolve
 method on the RegexURLPattern class is called, and hence subclasses can
 modify that behaviour. It however, '''doesn't''' work for URL reversal,
 because the resolver class generates the possible matches itself, instead
 of calling a method on RegexURLPattern or its subclasses as is the case
 with URL resolution.

 The attached patch simply refactors urlresolvers.py so the resolver calls
 a method on RegexURLPattern to get possible matches. It passes all the URL
 tests in Django, is completely backwards-compatible and introduces no new
 issues or quirks.

 I don't believe any new tests are required, and because the new method on
 RegexURLPattern is marked private (hence subject to change), no new docs
 are required either. This should stay as an unsupported way to extend
 Django's URL system until it is fully revamped (support disjunctives, URI
 templates etc.).

 The relevant thread on django-developers is here -
 http://groups.google.com/group/django-
 developers/browse_thread/thread/c94b551ebd57fbe6/65d79a336fef04b2

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

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

Re: [Django] #13223: ValueError with inline and save as new

[Django]

#13223: ValueError with inline and save as new
---+
  Reporter:  lucalenardi   | Owner:  gptvnt
Status:  assigned  | Milestone:
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:  admin, save-as-new
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by paulos):

 If inline formset contains an image or file field, form will always fail
 to validate on save_as (#14760).

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

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

Re: [Django] #14760: Admin inlines with file/image field fails to save_as

[Django]

#14760: Admin inlines with file/image field fails to save_as
---+
  Reporter:  paulos| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by paulos):

  * status:  closed => reopened
  * resolution:  duplicate =>

Comment:

 Seems to be related to #13223.

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

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

Re: [Django] #14760: Admin inlines with file/image field fails to save_as

[Django]

#14760: Admin inlines with file/image field fails to save_as
---+
  Reporter:  paulos| Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by paulos):

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

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

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

[Django] #14760: Admin inlines with file/image field fails to save_as

[Django]

#14760: Admin inlines with file/image field fails to save_as
--+-
 Reporter:  paulos|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 How to reproduce:
  * declare an admin inline which "model" property referes to a model
 containing an image field and another char field
  * declare a parent ModelAdmin having save_as=True
  * in the admin, create and save a new parent with one or more inlines
  * try to save_as

 Result:
  * the form does not validate, image or file field will be empty with
 error: "This field is required.", extra inlines gone.
  * if you try to upload other file admin blows up with ValueError: invalid
 literal for int() with base 10: ''

 Test case:
 - dummy/models.py
 {{{
 from django.db import models

 class Foo(models.Model):
 name = models.CharField(max_length=30)

 class Bar(models.Model):
 parent = models.ForeignKey(Foo)
 title = models.CharField(max_length=30)
 img = models.ImageField(upload_to='testpath')
 }}}
 - dummy/admin.py
 {{{
 from django.contrib import admin
 from bugtest.dummy.models import *

 class BarInline(admin.StackedInline):
 model = Bar

 class FooAdmin(admin.ModelAdmin):
 inlines = (BarInline,)
 save_as = True

 admin.site.register(Foo, FooAdmin)
 }}}

 Traceback:
 {{{
 Django Version: 1.2.3
 Python Version: 2.6.5
 Installed Applications:
 ['django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'django.contrib.messages',
  'django.contrib.admin',
  'django.contrib.admindocs',
  'bugtest.dummy',
 ]
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware')

 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/core/handlers/base.py" in
 get_response
   100. response = callback(request, *callback_args,
 **callback_kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/contrib/admin/options.py" in
 wrapper
   239. return self.admin_site.admin_view(view)(*args,
 **kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/utils/decorators.py" in
 _wrapped_view
   76. response = view_func(request, *args, **kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/views/decorators/cache.py" in
 _wrapped_view_func
   69. response = view_func(request, *args, **kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/contrib/admin/sites.py" in inner
   190. return view(request, *args, **kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/utils/decorators.py" in _wrapper
   21. return decorator(bound_func)(*args, **kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/utils/decorators.py" in
 _wrapped_view
   76. response = view_func(request, *args, **kwargs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/utils/decorators.py" in bound_func
   17. return func(self, *args2, **kwargs2)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/db/transaction.py" in
 _commit_on_success
   299. res = func(*args, **kw)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/contrib/admin/options.py" in
 add_view
   792.   prefix=prefix,
 queryset=inline.queryset(request))
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/forms/models.py" in __init__
   704. queryset=qs)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/forms/models.py" in __init__
   429. super(BaseModelFormSet, self).__init__(**defaults)
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/forms/formsets.py" in __init__
   47. self._construct_forms()
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/forms/formsets.py" in
 _construct_forms
   97. self.forms.append(self._construct_form(i))
 File "/usr/local/lib/python2.6/dist-
 packages/Django-1.2.3-py2.6.egg/django/forms/models.py" in _construct_form
   717. form = super(BaseInlineFormSet, self)._construct_form(i,
 **kwargs)
 File "/usr/local/lib/python2.6/

Re: [Django] #14043: Incorrect and/or confusing behaviour with nullable OneToOneField

[Django]

#14043: Incorrect and/or confusing behaviour with nullable OneToOneField
---+
  Reporter:  theevilgeek   | Owner: 
  
Status:  new   | Milestone:  1.3
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  
OneToOneField, cascading delete, nullable
 Stage:  Ready for checkin | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by ahebert):

 Looks like this is solved here. I'm adding a little more information for
 anyone who is trying to work around this in a pre-1.3 version of Django.
 The following modification fixed a similar problem on my model.


 {{{
 class Person(models.Model):
   age = models.PositiveIntegerField()

   def die(self):
 self.soul.become_ghost()
 # Update self here, so that self.soul is unavailalbe in the object
 passed to delete()
 # If self is left alone, then self.soul points to a python object
 representing a relationship
 # that was deleted from the database in the call to become_ghost().
 self = Person.objects.get(pk=self.pk)
 # OR, the following to work more generally:
 # self = self.__class__.objects.get(pk=self.pk)
 self.delete()


 class Soul(models.Model):
   person = models.OneToOneField(Person, null=True)
   is_alive = models.BooleanField(default=True)

   def become_ghost(self):
 self.person = None
 self.is_alive = False
 self.save()

 }}}

 I'd suggest it as a documentation change for earlier versions, but it's so
 hack-y.

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

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

[Changeset] r14686 - in django/trunk/docs: intro topics

[noreply]

Author: SmileyChris
Date: 2010-11-22 21:54:13 -0600 (Mon, 22 Nov 2010)
New Revision: 14686

Modified:
   django/trunk/docs/intro/install.txt
   django/trunk/docs/topics/install.txt
Log:
Fixes #6739 -- better development installation docs. Thanks to Adam Vandenberg 
for inspiration.

Modified: django/trunk/docs/intro/install.txt
===
--- django/trunk/docs/intro/install.txt 2010-11-23 02:46:55 UTC (rev 14685)
+++ django/trunk/docs/intro/install.txt 2010-11-23 03:54:13 UTC (rev 14686)
@@ -13,7 +13,10 @@
 version from 2.4 to 2.7 (due to backwards
 incompatibilities in Python 3.0, Django does not currently work with
 Python 3.0; see :doc:`the Django FAQ ` for more
-information on supported Python versions and the 3.0 transition), but we 
recommend installing Python 2.5 or later. If you do so, you won't need to set 
up a database just yet: Python 2.5 or later includes a lightweight database 
called SQLite_.
+information on supported Python versions and the 3.0 transition), but we
+recommend installing Python 2.5 or later. If you do so, you won't need to set
+up a database just yet: Python 2.5 or later includes a lightweight database
+called SQLite_.
 
 .. _sqlite: http://sqlite.org/
 
@@ -27,7 +30,8 @@
 
 .. _jython: http://www.jython.org/
 
-You can verify that Python's installed by typing ``python`` from your shell; 
you should see something like::
+You can verify that Python is installed by typing ``python`` from your shell;
+you should see something like::
 
 Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
 [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
@@ -74,7 +78,19 @@
 documentation marked **new in development version**. That phrase flags
 features that are only available in development versions of Django, and
 they likely won't work with an official release.
-
+
+
+Verifying
+-
+
+To verify that Django can be seen by Python, type ``python`` from your shell.
+Then at the Python prompt, try to import Django::
+
+>>> import django
+>>> print django.get_version()
+1.3
+
+
 That's it!
 --
 

Modified: django/trunk/docs/topics/install.txt
===
--- django/trunk/docs/topics/install.txt2010-11-23 02:46:55 UTC (rev 
14685)
+++ django/trunk/docs/topics/install.txt2010-11-23 03:54:13 UTC (rev 
14686)
@@ -161,6 +161,8 @@
 and remove the reference to the egg in the file named ``easy-install.pth``.
 This file should also be located in your ``site-packages`` directory.
 
+.. _finding-site-packages:
+
 .. admonition:: Where are my ``site-packages`` stored?
 
 The location of the ``site-packages`` directory depends on the operating
@@ -250,36 +252,22 @@
 
svn co http://code.djangoproject.com/svn/django/trunk/ django-trunk
 
-3. Next, make sure that the Python interpreter can load Django's code. There
-   are various ways of accomplishing this.  One of the most convenient, on
-   Linux, Mac OSX or other Unix-like systems, is to use a symbolic link:
+3. Next, make sure that the Python interpreter can load Django's code. The most
+   convenient way to do this is to
+   `modify Python's search path `_. Add a ``.pth``
+   file containing the full path to the ``django-trunk`` directory to your
+   system's ``site-packages`` directory. For example, on a Unix-like system:
 
.. code-block:: bash
 
-   ln -s WORKING-DIR/django-trunk/django SITE-PACKAGES-DIR/django
+   echo WORKING-DIR/django-trunk > SITE-PACKAGES-DIR/django.pth
 
(In the above line, change ``SITE-PACKAGES-DIR`` to match the location of
your system's ``site-packages`` directory, as explained in the
-   "Where are my ``site-packages`` stored?" section above. Change WORKING-DIR
-   to match the full path to your new ``django-trunk`` directory.)
+   :ref:`Where are my site-packages stored? ` section
+   above. Change ``WORKING-DIR/django-trunk`` to match the full path to your
+   new ``django-trunk`` directory.)
 
-   Alternatively, you can define your ``PYTHONPATH`` environment variable
-   so that it includes the ``django-trunk`` directory. This is perhaps the
-   most convenient solution on Windows systems, which don't support symbolic
-   links. (Environment variables can be defined on Windows systems `from the
-   Control Panel`_.)
-
-   .. admonition:: What about Apache and mod_wsgi?
-
-  If you take the approach of setting ``PYTHONPATH``, you'll need
-  to remember to do the same thing in your WSGI application once
-  you deploy your production site. Do this by appending to
-  ``sys.path`` in your WSGI application.
-
-  More information about deployment is available, of course, in our
-  :doc:`How to use Django with mod_wsgi `
-  documentation.
-
 4. On Unix-like systems, create a symbolic link to the file
``django-trunk/django/bin/django-admin.py`` in a directory on your system
path, such as ``/usr/loca

Re: [Django] #14415: Multiple aliases for one database: testing problems

[Django]

#14415: Multiple aliases for one database: testing problems
-+--
  Reporter:  shai| Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  Testing framework   |   Version:  1.2  

Resolution:  |  Keywords:  multidb, 
multiple databases, multiple aliases
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  1   |  
-+--
Comment (by russellm):

 @shai - Good call on the HOST issue - I've made that change; new patch
 incoming shortly.

 However, regarding the connection issue - I'm unclear whether what you
 consider correct behavior, and under what circumstances.

 The 'connection copying' behavior is only performed for the TEST_MIRROR
 case, and that behavior exists historically. To my mind, this is a bug;
 using connection obtained from the alias that is a TEST_MIRROR shouldn't
 affect transactions created using the connection that is being mirrored.
 The new patch addresses this bug.

 However, you seem to be implying that the same connection copying behavior
 exists for connections with a copied settings dictionary, which isn't the
 case. The patch I've provided causes your sample code to raise an
 exception at "transaction.commit(using=alias2)", because the code isn't
 under transaction management (for alias2) at that point.

 Have I misunderstood something here?

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

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

[Changeset] r14685 - django/trunk/docs/ref/forms

[noreply]

Author: SmileyChris
Date: 2010-11-22 20:46:55 -0600 (Mon, 22 Nov 2010)
New Revision: 14685

Modified:
   django/trunk/docs/ref/forms/widgets.txt
Log:
Fixes #14759 -- document the 'years' argument for SelectDateWidget. Thanks 
Bartolom?\195?\169 S?\195?\161nchez

Modified: django/trunk/docs/ref/forms/widgets.txt
===
--- django/trunk/docs/ref/forms/widgets.txt 2010-11-23 01:46:48 UTC (rev 
14684)
+++ django/trunk/docs/ref/forms/widgets.txt 2010-11-23 02:46:55 UTC (rev 
14685)
@@ -175,6 +175,13 @@
 Wrapper around three select widgets: one each for month, day, and year.
 Note that this widget lives in a separate file from the standard widgets.
 
+Takes one optional argument:
+
+.. attribute:: List.years
+
+An optional list/tuple of years to use in the "year" select box.
+The default is a list containing the current year and the next 9 years.
+
 .. code-block:: python
 
 from django.forms.extras.widgets import SelectDateWidget

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

[Django] #14759: Updated widgets doc.

[Django]

#14759: Updated widgets doc.
---+
 Reporter:  elbarto|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords:  SelectDateWidget, widgets  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 I have attached a patch in order to explain in the documentation the
 optional argument "years" for SelectDateWidget widget.

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

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

[Changeset] r14684 - in django/trunk: django/views/generic tests/regressiontests/generic_views

[noreply]

Author: russellm
Date: 2010-11-22 19:46:48 -0600 (Mon, 22 Nov 2010)
New Revision: 14684

Modified:
   django/trunk/django/views/generic/dates.py
   django/trunk/tests/regressiontests/generic_views/dates.py
   django/trunk/tests/regressiontests/generic_views/tests.py
   django/trunk/tests/regressiontests/generic_views/urls.py
Log:
Fixed #14752 -- Corrected date parsing in WeekArchiveView when using %W as a 
week format. Thanks to msundstr for the report and patch.

Modified: django/trunk/django/views/generic/dates.py
===
--- django/trunk/django/views/generic/dates.py  2010-11-22 21:55:29 UTC (rev 
14683)
+++ django/trunk/django/views/generic/dates.py  2010-11-23 01:46:48 UTC (rev 
14684)
@@ -348,9 +348,14 @@
 week = self.get_week()
 
 date_field = self.get_date_field()
+week_format = self.get_week_format()
+week_start = {
+'%W': '1',
+'%U': '0',
+}[week_format]
 date = _date_from_string(year, self.get_year_format(),
- '0', '%w',
- week, self.get_week_format())
+ week_start, '%w',
+ week, week_format)
 
 # Construct a date-range lookup.
 first_day = date

Modified: django/trunk/tests/regressiontests/generic_views/dates.py
===
--- django/trunk/tests/regressiontests/generic_views/dates.py   2010-11-22 
21:55:29 UTC (rev 14683)
+++ django/trunk/tests/regressiontests/generic_views/dates.py   2010-11-23 
01:46:48 UTC (rev 14684)
@@ -232,6 +232,16 @@
 res = self.client.get('/dates/books/2007/week/no_week/')
 self.assertEqual(res.status_code, 404)
 
+def test_week_start_Monday(self):
+# Regression for #14752
+res = self.client.get('/dates/books/2008/week/39/')
+self.assertEqual(res.status_code, 200)
+self.assertEqual(res.context['week'], datetime.date(2008, 9, 28))
+
+res = self.client.get('/dates/books/2008/week/39/monday/')
+self.assertEqual(res.status_code, 200)
+self.assertEqual(res.context['week'], datetime.date(2008, 9, 29))
+
 class DayArchiveViewTests(TestCase):
 fixtures = ['generic-views-test-data.json']
 urls = 'regressiontests.generic_views.urls'
@@ -349,4 +359,3 @@
 
 def test_invalid_url(self):
 self.assertRaises(AttributeError, self.client.get, 
"/dates/books/2008/oct/01/nopk/")
-

Modified: django/trunk/tests/regressiontests/generic_views/tests.py
===
--- django/trunk/tests/regressiontests/generic_views/tests.py   2010-11-22 
21:55:29 UTC (rev 14683)
+++ django/trunk/tests/regressiontests/generic_views/tests.py   2010-11-23 
01:46:48 UTC (rev 14684)
@@ -2,4 +2,4 @@
 from regressiontests.generic_views.dates import ArchiveIndexViewTests, 
YearArchiveViewTests, MonthArchiveViewTests, WeekArchiveViewTests, 
DayArchiveViewTests, DateDetailViewTests
 from regressiontests.generic_views.detail import DetailViewTest
 from regressiontests.generic_views.edit import CreateViewTests, 
UpdateViewTests, DeleteViewTests
-from regressiontests.generic_views.list import ListViewTests
\ No newline at end of file
+from regressiontests.generic_views.list import ListViewTests

Modified: django/trunk/tests/regressiontests/generic_views/urls.py
===
--- django/trunk/tests/regressiontests/generic_views/urls.py2010-11-22 
21:55:29 UTC (rev 14683)
+++ django/trunk/tests/regressiontests/generic_views/urls.py2010-11-23 
01:46:48 UTC (rev 14684)
@@ -149,6 +149,8 @@
 views.BookWeekArchive.as_view(allow_future=True)),
 (r'^dates/books/(?P\d{4})/week/no_week/$',
 views.BookWeekArchive.as_view()),
+(r'^dates/books/(?P\d{4})/week/(?P\d{1,2})/monday/$',
+views.BookWeekArchive.as_view(week_format='%W')),
 
 # DayArchiveView
 (r'^dates/books/(?P\d{4})/(?P[a-z]{3})/(?P\d{1,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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6739: How to add symbolic links in Windows Vista

[Django]

#6739: How to add symbolic links in Windows Vista
+---
  Reporter:  kwill  | Owner:  nobody
  
Status:  new| Milestone:
  
 Component:  Documentation  |   Version:  SVN   
  
Resolution: |  Keywords:  windows vista symbolic 
link installation development version svn
 Stage:  Accepted   | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Comment (by SmileyChris):

 And by "alternatively", I mean that I didn't read the whole of adamv's
 comment before replying. But yeah, my vote's for `.pth`

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

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

Re: [Django] #6739: How to add symbolic links in Windows Vista

[Django]

#6739: How to add symbolic links in Windows Vista
+---
  Reporter:  kwill  | Owner:  nobody
  
Status:  new| Milestone:
  
 Component:  Documentation  |   Version:  SVN   
  
Resolution: |  Keywords:  windows vista symbolic 
link installation development version svn
 Stage:  Accepted   | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Comment (by SmileyChris):

 Alternatively, I think the docs should just recommend creating a `.pth`
 file, as mentioned here: http://docs.python.org/install/index.html
 #modifying-python-s-search-path

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

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

Re: [Django] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
+---
  Reporter:  jkocherhans| Owner:  adrian
Status:  reopened   | Milestone:
 Component:  Core framework |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Fixed on a branch  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by dirleyrls):

 * cc: dirleyrls (added)

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

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

Re: [Django] #14758: QuerySet method docs headings contain entire method signatures

[Django]

#14758: QuerySet method docs headings contain entire method signatures
+---
  Reporter:  gabrielhurley  | Owner:  adamv
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  easy-pickings
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by adamv):

  * owner:  nobody => adamv
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

Re: [Django] #25: Filtering interface on ForeignKey boxes

[Django]

#25: Filtering interface on ForeignKey  boxes
---+
  Reporter:  adrian| Owner:  cpharmston
Status:  assigned  | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:  feature   
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by lrekucki):

 This is painfully slow for me right now. I tested this on Chrome 9.x with
 2000 objects named "user". After typing in "user" in the filter it took
 about 3-5 seconds to refresh (on a quite fast machine). Most of the time
 is spent on re-creating the  elements one-by-one. Creating all the
 HTML in one shot could improve this. Not creating elements again would be
 probably even better (i.e. keep the option elements in the cache).

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

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

Re: [Django] #14756: "Related objects reference" documentation needs copy-edit

[Django]

#14756: "Related objects reference" documentation needs copy-edit
+---
  Reporter:  deisner| Owner:  nobody   
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  1.3-alpha
Resolution: |  Keywords:  easy-pickings
 Stage:  Accepted   | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * milestone:  => 1.3
  * keywords:  => easy-pickings
  * needs_docs:  => 0
  * 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14758: QuerySet method docs headings contain entire method signatures

[Django]

#14758: QuerySet method docs headings contain entire method signatures
---+
 Reporter:  gabrielhurley  |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  1.2   
 Keywords:  easy-pickings  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Take a look at this URL (the URL itself, not the page):

 http://docs.djangoproject.com/en/dev/ref/models/querysets/#extra-select-
 none-where-none-params-none-tables-none-order-by-none-select-params-none

 Basically, the headings for the `QuerySet` methods (and consequently the
 hash for the anchors in the URLs) contain the entire method signature.
 This is completely non-functional (as opposed to the `:method:`
 declarations directly beneath the headings), it adds unnecessary detail to
 the page's TOC, and it makes the URLs for those anchors unbearably
 long/cluttered.

 As such, the headings for those methods should all be reduced to simply
 the name of the method, leaving the method signature defined below.

 It looks like the duplication stems from the headings having been written
 first, and left in place as-is after the method directives were added.

 The only downside to fixing this is that any existing external links
 directly to one of these anchors would now go to top of the page rather
 than directly to the section within the page.

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

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

Re: [Django] #14757: Add An Example For .extra(tables=[])

[Django]

#14757: Add An Example For .extra(tables=[])
+---
  Reporter:  mikeshultz | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:  documentation extra tables
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

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

Comment:

 Agreed. There is an example for `where`, but not for `tables`. Adding this
 would be helpful.

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

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

[Django] #14757: Add An Example For .extra(tables=[])

[Django]

#14757: Add An Example For .extra(tables=[])
+---
 Reporter:  mikeshultz  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.2   
 Keywords:  documentation extra tables  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 When fiddling around trying to find a solution to one of my problems, it
 seems to be that .extra(tables=[]) was what I needed.  I took a trip
 through the django documentation just to find that there were no examples,
 or even a description into what kind of 'string' it takes.  Is it JOIN
 statements?  Just a name of a table and/or matching columns?

 Please add an example to the documentation and/or a better explanation of
 the string it accepts.

 Reference: http://docs.djangoproject.com/en/dev/ref/models/querysets
 /#extra-select-none-where-none-params-none-tables-none-order-by-none-
 select-params-none

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

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

Re: [Django] #14415: Multiple aliases for one database: testing problems

[Django]

#14415: Multiple aliases for one database: testing problems
-+--
  Reporter:  shai| Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  Testing framework   |   Version:  1.2  

Resolution:  |  Keywords:  multidb, 
multiple databases, multiple aliases
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  1   |  
-+--
Comment (by shai):

 I think Russell's approach is closer to home, but there are still
 problems.

 For starters, the patch has a "surface" problem of identifying databases
 by their (Engine,Name) combination. The current docs about TEST_MIRROR
 (http://docs.djangoproject.com/en/dev/topics/testing/#testing-master-
 slave-configurations) show an example where this would be invalid (same
 name, different hosts). To fix this, it seems, we would need a notion of
 equivalence of settings -- `==` between dicts seems close enough for my
 taste (if a user defines two !MySql databases, one with `PORT=''` and
 another with `PORT='3306'`, I think they deserve the brouhaha they'll
 get), but I may be wrong (different OPTIONS'es, for example, for different
 transactional behavior, would seem legitimate).

 But there is a deeper problem: solving the issue by directing the actual
 connections -- not just fixing the creation/destruction issue -- would
 cause the test process to have different transaction semantics. Consider:
 {{{
 def do_stuff(alias1, alias2):

 with transaction.commit_manually(using=alias1)

 # Make an invalid change in an object

 m = MyModel.objects.get(pk=17)
 m.fld = 'invalid'
 m.save(using=alias1)

 # Commit other changes, but not the invalid change

 transaction.commit(using=alias2)

 # Roll back the invalid change

 transaction.rollback(using=alias1)

 # Check the outcome

 m1 = MyModel.objects.get(pk=17)
 assert m1.fld1 != 'invalid'
 }}}

 This will work in production, but fail in testing under t14415.diff.

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

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

[Django] #14756: "Related objects reference" documentation needs copy-edit

[Django]

#14756: "Related objects reference" documentation needs copy-edit
---+
 Reporter:  deisner|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.3-alpha 
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 On http://docs.djangoproject.com/en/dev/ref/models/relations/, we find
 (and in the v1.2 docs):

 "A “related manager” is a on managers used in a one-to-many or many-to-
 many related context."

 I suggest s/is a on managers/is a manager .

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

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

[Changeset] r14683 - in django/trunk: django/contrib/admin tests/regressiontests/admin_widgets

[noreply]

Author: Alex
Date: 2010-11-22 15:55:29 -0600 (Mon, 22 Nov 2010)
New Revision: 14683

Modified:
   django/trunk/django/contrib/admin/widgets.py
   django/trunk/tests/regressiontests/admin_widgets/models.py
   django/trunk/tests/regressiontests/admin_widgets/tests.py
Log:
Fixed #14424 -- corrected a NameError when instantiating a 
RelatedFieldWidgetWrapper.

Modified: django/trunk/django/contrib/admin/widgets.py
===
--- django/trunk/django/contrib/admin/widgets.py2010-11-22 18:02:33 UTC 
(rev 14682)
+++ django/trunk/django/contrib/admin/widgets.py2010-11-22 21:55:29 UTC 
(rev 14683)
@@ -203,7 +203,7 @@
 # Backwards compatible check for whether a user can add related
 # objects.
 if can_add_related is None:
-can_add_related = rel_to in self.admin_site._registry
+can_add_related = rel.to in admin_site._registry
 self.can_add_related = can_add_related
 # so we can check if the related object is registered with this 
AdminSite
 self.admin_site = admin_site

Modified: django/trunk/tests/regressiontests/admin_widgets/models.py
===
--- django/trunk/tests/regressiontests/admin_widgets/models.py  2010-11-22 
18:02:33 UTC (rev 14682)
+++ django/trunk/tests/regressiontests/admin_widgets/models.py  2010-11-22 
21:55:29 UTC (rev 14683)
@@ -1,9 +1,10 @@
 from django.db import models
 from django.contrib.auth.models import User
 
-class MyFileField(models.FileField): 
-pass 
 
+class MyFileField(models.FileField):
+pass
+
 class Member(models.Model):
 name = models.CharField(max_length=100)
 birthdate = models.DateTimeField(blank=True, null=True)

Modified: django/trunk/tests/regressiontests/admin_widgets/tests.py
===
--- django/trunk/tests/regressiontests/admin_widgets/tests.py   2010-11-22 
18:02:33 UTC (rev 14682)
+++ django/trunk/tests/regressiontests/admin_widgets/tests.py   2010-11-22 
21:55:29 UTC (rev 14683)
@@ -6,9 +6,9 @@
 from django.conf import settings
 from django.contrib import admin
 from django.contrib.admin import widgets
-from django.contrib.admin.widgets import FilteredSelectMultiple, 
AdminSplitDateTime
-from django.contrib.admin.widgets import (AdminFileWidget, 
ForeignKeyRawIdWidget,
-ManyToManyRawIdWidget)
+from django.contrib.admin.widgets import (FilteredSelectMultiple,
+AdminSplitDateTime, AdminFileWidget, ForeignKeyRawIdWidget, 
AdminRadioSelect,
+RelatedFieldWidgetWrapper, ManyToManyRawIdWidget)
 from django.core.files.storage import default_storage
 from django.core.files.uploadedfile import SimpleUploadedFile
 from django.db.models import DateField
@@ -31,7 +31,8 @@
 and verify that the returned formfield is appropriate.
 """
 # Override any settings on the model admin
-class MyModelAdmin(admin.ModelAdmin): pass
+class MyModelAdmin(admin.ModelAdmin):
+pass
 for k in admin_overrides:
 setattr(MyModelAdmin, k, admin_overrides[k])
 
@@ -314,3 +315,11 @@
 self.assertEqual(w._has_changed([1, 2], [u'1', u'2']), False)
 self.assertEqual(w._has_changed([1, 2], [u'1']), True)
 self.assertEqual(w._has_changed([1, 2], [u'1', u'3']), True)
+
+class RelatedFieldWidgetWrapperTests(DjangoTestCase):
+def test_no_can_add_related(self):
+rel = models.Inventory._meta.get_field('parent').rel
+w = AdminRadioSelect()
+# Used to fail with a name error.
+w = RelatedFieldWidgetWrapper(w, rel, admin.site)
+self.assertFalse(w.can_add_related)

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

[Django] #14755: Wsgi Error

[Django]

#14755: Wsgi Error
+---
 Reporter:  tolano  |   Owner:  nobody
   Status:  new |   Milestone:  1.3   
Component:  HTTP handling   | Version:  SVN   
 Keywords:  wski key input  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I'm testing a site with latest django trunk and latest development version
 of django-page-cms.

 When I try to add a new page, I get this error:


 {{{
 File "path/env/src/django-page-cms/pages/http.py", line 21, in
 get_request_mock
 'HTTP_HOST': 'testhost',

 File "path/env/lib/python2.5/site-packages/django/core/handlers/wsgi.py",
 line 137, in __init__
 if type(socket._fileobject) is type and
 isinstance(self.environ['wsgi.input'], socket._fileobject):

 KeyError: 'wsgi.input'

 }}}

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

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

Re: [Django] #14424: rel_to undefined in init scope of RelatedFieldWidgetWrapper

[Django]

#14424: rel_to undefined in init scope of RelatedFieldWidgetWrapper
---+
  Reporter:  robhudson | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.3-alpha
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * has_patch:  0 => 1

Comment:

 Bug introduced in revision [13708]

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

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

Re: [Django] #14424: rel_to undefined in init scope of RelatedFieldWidgetWrapper

[Django]

#14424: rel_to undefined in init scope of RelatedFieldWidgetWrapper
---+
  Reporter:  robhudson | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.3-alpha
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by fantoma...@gmail.com):

  * needs_better_patch:  => 0
  * version:  1.2 => 1.3-alpha
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This bug is not present in the 1.2.x versions but he is present in the
 1.3-alpha-1

 And 2 mistakes are present in this line. See patch for correction.

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

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

[Changeset] r14682 - in django/branches/releases/1.2.X: django/db/models/sql tests/regressiontests/aggregation_regress

[noreply]

Author: Alex
Date: 2010-11-22 12:02:33 -0600 (Mon, 22 Nov 2010)
New Revision: 14682

Modified:
   django/branches/releases/1.2.X/django/db/models/sql/expressions.py
   
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/models.py
   
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
Log:
[1.2.X] Fixed #14754 -- corrected using an aggregate in an F expressions when 
that queryset is later used in a subquery.  Thanks to master for the patch. 
Backport of [14681].

Modified: django/branches/releases/1.2.X/django/db/models/sql/expressions.py
===
--- django/branches/releases/1.2.X/django/db/models/sql/expressions.py  
2010-11-22 18:00:01 UTC (rev 14681)
+++ django/branches/releases/1.2.X/django/db/models/sql/expressions.py  
2010-11-22 18:02:33 UTC (rev 14682)
@@ -19,7 +19,10 @@
 
 def relabel_aliases(self, change_map):
 for node, col in self.cols.items():
-self.cols[node] = (change_map.get(col[0], col[0]), col[1])
+if hasattr(col, "relabel_aliases"):
+col.relabel_aliases(change_map)
+else:
+self.cols[node] = (change_map.get(col[0], col[0]), col[1])
 
 #
 # Vistor methods for initial expression preparation #

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/models.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/models.py
  2010-11-22 18:00:01 UTC (rev 14681)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/models.py
  2010-11-22 18:02:33 UTC (rev 14682)
@@ -1,10 +1,7 @@
 # coding: utf-8
-import pickle
+from django.db import models
 
-from django.db import connection, models, DEFAULT_DB_ALIAS
-from django.conf import settings
 
-
 class Author(models.Model):
 name = models.CharField(max_length=100)
 age = models.IntegerField()
@@ -49,7 +46,6 @@
 def __unicode__(self):
 return self.name
 
-
 class Entries(models.Model):
 EntryID = models.AutoField(primary_key=True, db_column='Entry ID')
 Entry = models.CharField(unique=True, max_length=50)

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
   2010-11-22 18:00:01 UTC (rev 14681)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
   2010-11-22 18:02:33 UTC (rev 14682)
@@ -1,13 +1,15 @@
 import datetime
+import pickle
 from decimal import Decimal
+from operator import attrgetter
 
+from django.conf import settings
 from django.core.exceptions import FieldError
-from django.conf import settings
-from django.test import TestCase, Approximate
 from django.db import DEFAULT_DB_ALIAS
 from django.db.models import Count, Max, Avg, Sum, StdDev, Variance, F
+from django.test import TestCase, Approximate
 
-from regressiontests.aggregation_regress.models import *
+from models import Author, Book, Publisher, Clues, Entries, HardbackBook
 
 
 def run_stddev_tests():
@@ -501,7 +503,7 @@
 # Regression for #10197 -- Queries with aggregates can be pickled.
 # First check that pickling is possible at all. No crash = success
 qs = Book.objects.annotate(num_authors=Count('authors'))
-out = pickle.dumps(qs)
+pickle.dumps(qs)
 
 # Then check that the round trip works.
 query = qs.query.get_compiler(qs.db).as_sql()[0]
@@ -659,6 +661,20 @@
 Author.objects.count()
 )
 
+def test_f_expression_annotation(self):
+# Books with less than 200 pages per author.
+qs = Book.objects.values("name").annotate(
+n_authors=Count("authors")
+).filter(
+pages__lt=F("n_authors") * 200
+).values_list("pk")
+self.assertQuerysetEqual(
+Book.objects.filter(pk__in=qs), [
+"Python Web Development with Django"
+],
+attrgetter("name")
+)
+
 if run_stddev_tests():
 def test_stddev(self):
 self.assertEqual(

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

[Changeset] r14681 - in django/trunk: django/db/models/sql tests/regressiontests/aggregation_regress

[noreply]

Author: Alex
Date: 2010-11-22 12:00:01 -0600 (Mon, 22 Nov 2010)
New Revision: 14681

Modified:
   django/trunk/django/db/models/sql/expressions.py
   django/trunk/tests/regressiontests/aggregation_regress/models.py
   django/trunk/tests/regressiontests/aggregation_regress/tests.py
Log:
Fixed #14754 -- corrected using an aggregate in an F expressions when that 
queryset is later used in a subquery.  Thanks to master for the patch.

Modified: django/trunk/django/db/models/sql/expressions.py
===
--- django/trunk/django/db/models/sql/expressions.py2010-11-22 12:29:22 UTC 
(rev 14680)
+++ django/trunk/django/db/models/sql/expressions.py2010-11-22 18:00:01 UTC 
(rev 14681)
@@ -19,7 +19,10 @@
 
 def relabel_aliases(self, change_map):
 for node, col in self.cols.items():
-self.cols[node] = (change_map.get(col[0], col[0]), col[1])
+if hasattr(col, "relabel_aliases"):
+col.relabel_aliases(change_map)
+else:
+self.cols[node] = (change_map.get(col[0], col[0]), col[1])
 
 #
 # Vistor methods for initial expression preparation #

Modified: django/trunk/tests/regressiontests/aggregation_regress/models.py
===
--- django/trunk/tests/regressiontests/aggregation_regress/models.py
2010-11-22 12:29:22 UTC (rev 14680)
+++ django/trunk/tests/regressiontests/aggregation_regress/models.py
2010-11-22 18:00:01 UTC (rev 14681)
@@ -1,10 +1,7 @@
 # coding: utf-8
-import pickle
+from django.db import models
 
-from django.db import connection, models, DEFAULT_DB_ALIAS
-from django.conf import settings
 
-
 class Author(models.Model):
 name = models.CharField(max_length=100)
 age = models.IntegerField()
@@ -49,7 +46,6 @@
 def __unicode__(self):
 return self.name
 
-
 class Entries(models.Model):
 EntryID = models.AutoField(primary_key=True, db_column='Entry ID')
 Entry = models.CharField(unique=True, max_length=50)

Modified: django/trunk/tests/regressiontests/aggregation_regress/tests.py
===
--- django/trunk/tests/regressiontests/aggregation_regress/tests.py 
2010-11-22 12:29:22 UTC (rev 14680)
+++ django/trunk/tests/regressiontests/aggregation_regress/tests.py 
2010-11-22 18:00:01 UTC (rev 14681)
@@ -1,13 +1,13 @@
 import datetime
+import pickle
 from decimal import Decimal
+from operator import attrgetter
 
 from django.core.exceptions import FieldError
-from django.conf import settings
 from django.test import TestCase, Approximate, skipUnlessDBFeature
-from django.db import DEFAULT_DB_ALIAS
 from django.db.models import Count, Max, Avg, Sum, StdDev, Variance, F
 
-from regressiontests.aggregation_regress.models import *
+from models import Author, Book, Publisher, Clues, Entries, HardbackBook
 
 
 class AggregationTests(TestCase):
@@ -482,7 +482,7 @@
 # Regression for #10197 -- Queries with aggregates can be pickled.
 # First check that pickling is possible at all. No crash = success
 qs = Book.objects.annotate(num_authors=Count('authors'))
-out = pickle.dumps(qs)
+pickle.dumps(qs)
 
 # Then check that the round trip works.
 query = qs.query.get_compiler(qs.db).as_sql()[0]
@@ -640,6 +640,20 @@
 Author.objects.count()
 )
 
+def test_f_expression_annotation(self):
+# Books with less than 200 pages per author.
+qs = Book.objects.values("name").annotate(
+n_authors=Count("authors")
+).filter(
+pages__lt=F("n_authors") * 200
+).values_list("pk")
+self.assertQuerysetEqual(
+Book.objects.filter(pk__in=qs), [
+"Python Web Development with Django"
+],
+attrgetter("name")
+)
+
 @skipUnlessDBFeature('supports_stddev')
 def test_stddev(self):
 self.assertEqual(

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

Re: [Django] #12522: Unable to get request.POST after request.get_raw_post_data

[Django]

#12522: Unable to get request.POST after request.get_raw_post_data
+---
  Reporter:  redbaron   | Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by zimnyx):

 Another related issue: #14753 (Accessing (Get)HttpRequest.raw_post_data in
 view results in exception during testing)

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

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

Re: [Django] #13883: SelectBox.js with grouping (optgroup elements)

[Django]

#13883: SelectBox.js with grouping (optgroup elements)
---+
  Reporter:  SardarNL  | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  admin, SelectBox, 
optgroup
 Stage:  Unreviewed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by hvdklauw):

  * milestone:  => 1.3

Comment:

 Works great, it doesn't change the current working of the select but adds
 extra functionality.

 I dunno if there are tests for the admin javascript, so it might need that
 and I really wouldn't know what documentation it would need.

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

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

Re: [Django] #6663: UUID as Primary Key (Re. 4682)

[Django]

#6663: UUID as Primary Key (Re. 4682)
+---
  Reporter:  Jonathan Harker   | Owner:  
nobody   
Status:  closed | Milestone:
   
 Component:  Database layer (models, ORM)   |   Version:  1.2   
   
Resolution:  invalid|  Keywords:  
primary key, uuid
 Stage:  Unreviewed | Has_patch:  0 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by carljm):

  * status:  reopened => closed
  * resolution:  => invalid

Comment:

 This ticket is invalid, because it's requesting something that already
 exists in Django core; the ability to use a UUIDField (or any other type
 of field) instead of the automatic auto-increment id field as the primary
 key for a model.

 If you are wanting to advocate for inclusion of a UUIDField in Django core
 (which is what it sounds like), that's #4682, not this ticket. But
 reopening tickets that have been closed wontfix by core developers is not
 helpful and against the
 [http://docs.djangoproject.com/en/dev/internals/contributing/ contributing
 guidelines]. Useful things you could do to advocate for this would include
 starting a conversation on the django-developers mailing list with
 arguments for inclusion of a UUIDField in core, and working on an external
 UUIDField implementation to get it into shape that it could be ready for
 core. (Keep in mind that the absence of an external "implementation
 without issue" is an argument against, not in favor of, adding UUIDField
 to core. Making the decision to add something to core does not magically
 make it work better.)

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

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

[Django] #14754: TypeError: '[some aggregate function]' object does not support indexing

[Django]

#14754: TypeError: '[some aggregate function]' object does not support indexing
--+-
 Reporter:  master|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  relabel_aliases, aggregate|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Relabelling aliases on the query value, when this value is an Aggregate
 object, is expected.

 A simplified example (don't look for a sense, it's just for the demo):

 {{{
 from django.contrib.auth.models import User
 emails = User.objects.values('email').annotate(
 cnt=Count('id'),
 some_int=Count('username')
 ).filter(some_int=F('cnt')).values_list('email', flat=True)
 print User.objects.filter(email__in=emails).query
 }}}

 produces:

 {{{
   File "D:\Python26\lib\site-packages\django-
 svn\django\db\models\sql\query.py", line 709, in change_aliases
 self.having.relabel_aliases(change_map)
   File "D:\Python26\lib\site-packages\django-
 svn\django\db\models\sql\where.py", line 251, in relabel_aliases
 child[3].relabel_aliases(change_map)
   File "D:\Python26\lib\site-packages\django-
 svn\django\db\models\sql\expressions.py", line 22, in relabel_aliases
 self.cols[node] = (change_map.get(col[0], col[0]), col[1])
 TypeError: 'Count' object does not support indexing
 }}}

 A patch is provided, for django\db\models\sql\expressions.py

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

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

[Django] #14753: Accessing (Get)HttpRequest.raw_post_data in view results in exception during testing

[Django]

#14753: Accessing (Get)HttpRequest.raw_post_data in view results in exception
during testing
---+
 Reporter:  zimnyx |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 (Confirmed with Django trunk r14680)

 This happens only when running tests and test client makes GET request.
 When views is accessed under runserver, it serves empty page as desired -
 no exception is raised.

 {{{
 # view
 def zoo(response):
 return HttpResponse(response.raw_post_data)
 }}}

 {{{
 #view test
 class SimpleTest(TestCase):
 def test_lala(self):
 c = Client()
 res = c.get('/')
 }}}

 {{{
 /tmp/zoo$ time python manage.py test --failfast
 Creating test database for alias 'default'...
 F
 ==
 FAIL: test_lala (zoo.lew.tests.SimpleTest)
 --
 Traceback (most recent call last):
   File "/tmp/zoo/../zoo/lew/tests.py", line 15, in test_lala
 res = c.get('/')
   File "/tmp/zoo/django/test/client.py", line 434, in get
 response = super(Client, self).get(path, data=data, **extra)
   File "/tmp/zoo/django/test/client.py", line 218, in get
 return self.request(**r)
   File "/tmp/zoo/django/core/handlers/base.py", line 109, in get_response
 response = callback(request, *callback_args, **callback_kwargs)
   File "/tmp/zoo/../zoo/lew/views.py", line 6, in zoo
 return HttpResponse(re.raw_post_data)
   File "/tmp/zoo/django/http/__init__.py", line 153, in _get_raw_post_data
 self._raw_post_data = self.read()
   File "/tmp/zoo/django/http/__init__.py", line 199, in read
 return self._stream.read(*args, **kwargs)
   File "/tmp/zoo/django/test/client.py", line 50, in read
 assert self.__len >= num_bytes, "Cannot read more than the available
 bytes from the HTTP incoming data."
 AssertionError: Cannot read more than the available bytes from the HTTP
 incoming data.
 }}}

 I can agree that accessing raw_post_data in case of GET request is weird,
 but nevertheless such issue should be handled in consistent way no matter
 if it's request via Django's test client or real http request handled by
 runserver.

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

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

Re: [Django] #13860: Translate the output of admin commands

[Django]

#13860: Translate the output of admin commands
---+
  Reporter:  tonnzor   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by tonnzor):

 My suggestion was to translate output of ./manage.py XXX commands -
 without translating commands or arguments.

 Using environment language is a great idea as I always may configure this
 for myself. However, in some environments it's not possible (shared
 hosting) - so we should use settings.LANGUAGE_CODE before trying to apply
 ENV language.

 Maybe it makes sense to define another settings (ADMIN_LANGUAGE_CODE) or
 argument (--lang=ru) for this (let's say my site is in English but I want
 to admin it in Russian).

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

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

Re: [Django] #14710: Form css classes for bound fields are not rendered {{ form.field_name }}

[Django]

#14710: Form css classes for bound fields are not rendered {{ form.field_name }}
-+--
  Reporter:  trebor74hr  | Owner:  trebor74hr
Status:  assigned| Milestone:  1.3   
 Component:  Forms   |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by akaariai):

  * stage:  Unreviewed => Design decision needed

Comment:

 If I am not mistaken, before the patch the classes were not assigned to
 the input tags, that is the output was like this:
 {{{
 
 This field is required.
 Name:
 
 
 }}}

 In the original report it is claimed that the input tag has the class
 attributes, but at least according to the test changes this is not the
 case.

 The big question in this patch is if this is something that will be
 backwards incompatible. People might have css styling applying to just
 .error or .required, and this styling would affect the  tag after
 Django update. I think this is not acceptable, but leaving as DDN.

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

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

Re: [Django] #14742: Allow each action to decide default value for select_across

[Django]

#14742: Allow each action to decide default value for select_across
---+
  Reporter:  cur...@tinbrain.net   | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  1.3-alpha 
Resolution:  invalid   |  Keywords:  admin, actions
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by cur...@tinbrain.net):

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

Comment:

 Thanks to SmileyChris for making me realise I'd misunderstood the 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #3544: Fix {% include %} to allow recursive includes

[Django]

#3544: Fix {% include %} to allow recursive includes
+---
  Reporter:  David Danier   | 
Owner:  nobody   
Status:  new| 
Milestone:   
 Component:  Template system|   
Version:  SVN  
Resolution: |  
Keywords:  tplrf-patched
 Stage:  Accepted   | 
Has_patch:  0
Needs_docs:  1  |   
Needs_tests:  1
Needs_better_patch:  1  |  
+---
Comment (by twoolie):

 > So what needs to be changes is, that {% include %} needs to hase some
 kind of registry which templates alreads were loaded and not to reload
 them. Meaning {% include "some/file.html" %} loads the template and fires
 up the parser. Every folowing {% include "some/file.html" %} should not do
 that, regardless of this happens as a recursive call or not. This could
 even improve performance in non-recursive use cases.

 This is obviously beneficial
 >Isn't that what "django.template.loaders.cached.Loader" does ?

 Not really, the caching system returns Template objects, whereas if the
 include tag doesn't need to touch the entire template discovery stack
 every time, that would be awesome. an include tag local cache only costs
 one reference per included template so why not? if it speeds up include
 performance AND allows recursive imports then why not?
 also, embedded '''with''' syntax is insanely cool

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

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

[Changeset] r14680 - django/trunk/docs/howto/deployment

[noreply]

Author: russellm
Date: 2010-11-22 06:29:22 -0600 (Mon, 22 Nov 2010)
New Revision: 14680

Modified:
   django/trunk/docs/howto/deployment/modpython.txt
Log:
Clarified a comment in the mod_python docs on the status of the handler. Thanks 
to mattmcc for the report.

Modified: django/trunk/docs/howto/deployment/modpython.txt
===
--- django/trunk/docs/howto/deployment/modpython.txt2010-11-22 12:13:18 UTC 
(rev 14679)
+++ django/trunk/docs/howto/deployment/modpython.txt2010-11-22 12:29:22 UTC 
(rev 14680)
@@ -4,10 +4,11 @@
 
 .. warning::
 
-Support for mod_python will be deprecated in a future release of Django. If
-you are configuring a new deployment, you are strongly encouraged to
-consider using :doc:`mod_wsgi ` or any of the
-other :doc:`supported backends `.
+Support for mod_python has been deprecated, and will be removed in
+Django 1.5. If you are configuring a new deployment, you are
+strongly encouraged to consider using :doc:`mod_wsgi
+` or any of the other :doc:`supported
+backends `.
 
 .. highlight:: apache
 
@@ -218,15 +219,15 @@
 
 .. _cause response errors: 
http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html
 
-If you have the need to print debugging information in a mod_python setup, you 
+If you have the need to print debugging information in a mod_python setup, you
 have a few options. You can print to ``stderr`` explicitly, like so::
- 
+
 print >> sys.stderr, 'debug text'
 sys.stderr.flush()
- 
+
 (note that ``stderr`` is buffered, so calling ``flush`` is necessary if you 
wish
 debugging information to be displayed promptly.)
- 
+
 A more compact approach is to use an assertion::
 
 assert False, 'debug text'

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

Re: [Django] #14752: WeekArchiveView gives incorrect results when using weeks beginning with Monday

[Django]

#14752: WeekArchiveView gives incorrect results when using weeks beginning with
Monday
+---
  Reporter:  msundstr   | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Generic views  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Comment (by msundstr):

 Replying to [comment:1 lrekucki]:
 > The patch looks ok, but both tests and the fix should be in a single
 diff - it's easier to test that way.

 Okay, see combined.diff

 I had separated them because I thought it would be easier to demonstrate
 the problem, i.e.: apply the test patch, see the bug, apply the fix, see
 the bug go away.

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

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

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

[noreply]

Author: russellm
Date: 2010-11-22 06:13:18 -0600 (Mon, 22 Nov 2010)
New Revision: 14679

Modified:
   django/trunk/docs/releases/1.3.txt
Log:
Clarified the text describing the deprecation status of mod_python. Thanks to 
mattmcc and Tai Lee for pointing out the ambiguity.

Modified: django/trunk/docs/releases/1.3.txt
===
--- django/trunk/docs/releases/1.3.txt  2010-11-22 06:44:59 UTC (rev 14678)
+++ django/trunk/docs/releases/1.3.txt  2010-11-22 12:13:18 UTC (rev 14679)
@@ -334,9 +334,12 @@
 has shifted all of his efforts toward the lighter, slimmer, more stable, and
 more flexible ``mod_wsgi`` backend.
 
-If you are currently using the ``mod_python`` request handler, it is strongly
-encouraged you redeploy your Django instances using :doc:`mod_wsgi
-`.
+If you are currently using the ``mod_python`` request handler, you
+should redeploy your Django projects using another request handler.
+:doc:`mod_wsgi ` is the request handler
+recommended by the Django project, but :doc:`FastCGI
+` is also supported. Support for
+``mod_python`` deployment will be removed in Django 1.5.
 
 Function-based generic views
 

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

Re: [Django] #14752: WeekArchiveView gives incorrect results when using weeks beginning with Monday

[Django]

#14752: WeekArchiveView gives incorrect results when using weeks beginning with
Monday
+---
  Reporter:  msundstr   | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Generic views  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by lrekucki):

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

Comment:

 The patch looks ok, but both tests and the fix should be in a single diff
 - it's easier to test that way.

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

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

Re: [Django] #14731: [Patch] Change 14413 breaks old fixtures with permissions

[Django]

#14731: [Patch] Change 14413 breaks old fixtures with permissions
-+--
  Reporter:  chipx86 | Owner:  nobody   
Status:  new | Milestone:  1.3  
 Component:  Authentication  |   Version:  1.3-alpha
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Comment (by chipx86):

 The new patch includes regression tests. Let me know if you want anything
 done differently there.

 The regression test has been tested with r14412 (last known good
 revision), r14412 (first broken revision), and r14678 (HEAD at the time of
 this writing), both with and without the fix.

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

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

[Django] #14752: WeekArchiveView gives incorrect results when using weeks beginning with Monday

[Django]

#14752: WeekArchiveView gives incorrect results when using weeks beginning with
Monday
---+
 Reporter:  msundstr   |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Generic views  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 WeekArchiveView defaults to weeks defined as beginning on Sunday (the
 strptime '%U' format) and this works correctly. Using weeks defined as
 beginning on Monday ('%W'), gives incorrect results. This is because
 BaseWeekArchiveView.get_dated_items calls the helper function,
 _date_from_string, with the wrong format.

 For example, for the 10th week in 2009, beginning on Sunday, it correctly
 constructs the following:
{{{ time.strptime('2009__0__10', '%Y__%w__%U') }}}
 However, for the 10th week in 2009, beginning on Monday, it incorrectly
 constructs:
{{{ time.strptime('2009__0__10', '%Y__%w__%W') }}}
 This can be fixed by using:
   {{{ time.strptime('2009__1__10', '%Y__%w__%W') }}}
 The '1' refers to the day of the week being Monday (Sunday = 0).

 I've attached a patch, tests.diff, which demonstrates the problem, and
 another patch, dates.diff, with the correction.

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

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

Re: [Django] #14751: online casinos

[Django]

#14751: online casinos
+---
  Reporter:  bertus01   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  fixed  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by bertus01):

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

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

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

Re: [Django] #14013: 'django.db.backends.postgresql_psycopg2' isn't an available database backend. (?!?!?)

[Django]

#14013: 'django.db.backends.postgresql_psycopg2' isn't an available database
backend. (?!?!?)
---+
  Reporter:  kessler...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Sin):

 I've solved this problem using MinGW compilator for psycopg2-2.2.2.
 Anything works OK!

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

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

[Django] #14751: online casinos

[Django]

#14751: online casinos
---+
 Reporter:  bertus01   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 A Thorough Pass to Blackjack and Internet Casino Websites

 By And Large, gaming, more usually recognized as gaming, is a form of
 behavior that needs money being put out to risk as a production of a
 thorough game. So to talk, the money or valuables are at chance because
 the chance of winning is too low or is all based upon chance. Unless some
 other one will do something about his winning through evil ways, one could
 never be certain of winning a gambling game.

 Both vincible and invincible wagering games can be obtained at
 [http://www.hypercasinos.com online casinos]. Though, on that point are
 other gaming games that are not played inside the casinos such as
 blackjack, poker, keno, coin-tossing games such as bingo, and carnival
 games like bingo.
 At opposite sites. like [http://www.officialsportsbetting.com sports
 betting] and [http://www.officialsportsbetting.com/news/nfl-betting NFL
 betting], there are also the so-called fixed-odds wagering that can be
 seen on events like football, golf, NFL football, horse racing, baseball,
 and other sports that entice people to bet on the winner of the event.

 wagering comes in many forms: one that can be conquerable and the other
 type is not.
 vincible games of playing refer to games that can be trampled thereby
 creating a positive numerical chance through proper strategy. These
 includes video slots, though this is better classified as a game of skill;
 slots, bingo, poker and blackjack, sports gaming, pony racing, and video
 slots.
 Then Again, unbeatable games makes a participant finally lose a game no
 matter what strategy they use. to a greater extent mundane examples of
 these games are poker, poker, craps, poker, slots, casino war, bacarrat,
 poker, bingo, bacarrat, video slots, bacarrat, and bacarrat.

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

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

Re: [Django] #14013: 'django.db.backends.postgresql_psycopg2' isn't an available database backend. (?!?!?)

[Django]

#14013: 'django.db.backends.postgresql_psycopg2' isn't an available database
backend. (?!?!?)
---+
  Reporter:  kessler...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Sin):

 psycopg2-2.2.2\psycopg2-2.2.2\setup.py

 def finalize_win32(self):
 ...
 self.libraries.append("crypt32") <--- here is the promlem IMHO

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

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Comment (by jovanb):

 Replying to [comment:69 bendavis78]:

 Custom FilterSpec on a Model level instead of field level is frequently
 needed feature (ast least in my case), so thumbs-up for this 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly

[Django]

#14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly
-+--
  Reporter:  idangazit   | Owner:  idangazit
Status:  assigned| Milestone:   
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by idangazit):

 Not sure this needs tests since the existing tests already try out
 valid/invalid values as well as every member of EMPTY_VALUES.

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

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

Re: [Django] #14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly

[Django]

#14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly
-+--
  Reporter:  idangazit   | Owner:  idangazit
Status:  assigned| Milestone:   
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by idangazit):

  * has_patch:  0 => 1

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

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

[Django] #14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly

[Django]

#14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly
+---
 Reporter:  idangazit   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  django.contrib.localflavor  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Same issue as #14499.

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

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

Re: [Django] #14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly

[Django]

#14750: ILPostalCodeField doesn't handle EMPTY_VALUES correctly
-+--
  Reporter:  idangazit   | Owner:  idangazit
Status:  assigned| Milestone:   
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by idangazit):

  * owner:  nobody => idangazit
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

Re: [Django] #14499: ATSocialSecurityNumberField doesn't handle EMPTY_VALUES correctly

[Django]

#14499: ATSocialSecurityNumberField doesn't handle EMPTY_VALUES correctly
-+--
  Reporter:  idangazit   | Owner:  idangazit
Status:  new | Milestone:   
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by idangazit):

  * summary:  Some localflavor fields don't handle EMPTY_VALUES correctly
  => ATSocialSecurityNumberField doesn't handle
  EMPTY_VALUES correctly

Comment:

 Updating to split instances of this issue into separate tickets.

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

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