Re: [Django] #16400: runserver exits without any warnings

[Django]

#16400: runserver exits without any warnings
--+--
   Reporter:  gour|  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Core (Other)
Version:  1.3 |   Severity:  Normal
 Resolution:  invalid |   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:  reopened => closed
 * resolution:   => invalid


Comment:

 Some code must have changed between Django 1.2 and 1.3 and it triggers the
 bug, that's all...

 Since it's a problem with the version of Python provided by FreeBSD, I'll
 close the ticket.

 Thanks for your efforts to diagnose 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.

Re: [Django] #16422: Warnings when building the docs in epub format

[Django]

#16422: Warnings when building the docs in epub format
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I couldn't find a way to remove these warnings.

 Also http://sphinx.readthedocs.org/en/latest/faq.html#epub-info says:
 >The epub builder is currently in an experimental stage. It has only been
 tested with the Sphinx documentation itself.

 Until it's really supported by Sphinx, WONTFIX.

-- 
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] #16422: Warnings when building the docs in epub format

[Django]

#16422: Warnings when building the docs in epub format
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * 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.

Re: [Django] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
-+-
   Reporter:  haras  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * severity:  Release blocker => Normal
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 `django.contrib.auth` uses the `get_current_site` method of
 `django.contrib.sites`, which is safe to use, whether the sites framework
 is or isn't enabled.

 However, when the sites framework isn't enabled, this method must receive
 the `request` in argument. In `test_custom_email_subject`, there is no
 request available, and the test crashes. Attached patch fixes this (and
 avoids relying on the default name of the default site).

-- 
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] #16400: runserver exits without any warnings

[Django]

#16400: runserver exits without any warnings
--+--
   Reporter:  gour|  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  Core (Other)
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--

Comment (by gour):

 Replying to [comment:4 aaugustin]:
 > Since we have a segfault, either Django is doing bad things with
 `ctypes`, or it's a bug in Python.
 >
 > It might be http://bugs.python.org/issue9812 but I really don't have any
 proof of this.

 It seems it is problem with Python...iow, I've rebuilt Python with 'Use a
 larger thread stack' (HUGE_STACK_SIZE) which defines:

 {{{
 CFLAGS += -DTHREAD_STACK_SIZE=0x10
 }}}

 and now it works.

 I'll inform port maintainers, since the 'default' size of 0x2 seems to
 be quite small.

 Now I just wonder why it works with django-1.2.5?

-- 
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] #16400: runserver exits without any warnings

[Django]

#16400: runserver exits without any warnings
--+--
   Reporter:  gour|  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  Core (Other)
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--

Comment (by gour):

 Replying to [comment:4 aaugustin]:
 > It might be http://bugs.python.org/issue9812 but I really don't have any
 proof of this.

 I've tried that, but it does not crash.

 > Next step: http://wiki.python.org/moin/DebuggingWithGdb

 Installed gdb72 with python support, but not getting much...

 {{{

 (gdb) run manage.py runserver
 Starting program: /usr/home/gour/www/dj13/bin/python manage.py runserver
 [New LWP 100461]
 [New Thread 801407400 (LWP 100461)]
 Validating models...

 0 errors found
 Django version 1.3, using settings 'tst.settings'
 Development server is running at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.

 Program exited with code 0365.
 }}}

 Will try further to get some useful trace or something.

-- 
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] #16409: `defer()` and `only()` don't play nice with `annotate()`

[Django]

#16409: `defer()` and `only()` don't play nice with `annotate()`
-+-
   Reporter:  mrmachine  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  annotate defer only
  Unreviewed |  count
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by mrmachine):

 Updated tests to use `assertIsInstance`. The test checks that the queryset
 can be successfully iterated through without raising an exception by
 converting it to a list.

-- 
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] #16422: Warnings when building the docs in epub format

[Django]

#16422: Warnings when building the docs in epub format
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by alexandrul):

 I get an extra warning, so maybe .xml mimetype should also be added:

 {{{WARNING: unknown mimetype for META-INF\container.xml, ignoring}}}

-- 
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] #16423: ModelForm._post_clean() does not respect Model.clean() ValidationErrors that possess a message_dict, rather than a list of messages

[Django]

#16423: ModelForm._post_clean() does not respect Model.clean() ValidationErrors
that possess a message_dict, rather than a list of messages
---+
 Reporter:  robboyle   |  Owner:  nobody
 Type:  Cleanup/optimization   | Status:  new
Milestone: |  Component:  Forms
  Version:  1.3|   Severity:  Normal
 Keywords:  modelform, validation  |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
 When a ModelForm runs it's model-level validation, it anticipates the
 Model's clean_fields() method raising a ValidationError with the
 message_dict property set. This let's the ModelForm associate the Model's
 Field validation errors with the ModelForm fields.

 However, when the ModelForm then calls the Model's clean() method, it
 ignores the message_dict property if the ValidationError raised by clean()
 has it set. Instead, it always creates a new dictionary, associating all
 validation messages with the NON_FIELD_ERRORS key.

 It would be nice if _post_clean() checked if Model.clean() was raising a
 ValidationError with a message_dict, and if so updated the errors with
 that dict, rather than blindly creating a new one. That way, the
 Model.clean() method could associate errors with a particular field,
 return a ValidationError with message_dict set, and this association would
 be perserved by the ModelForm.

 Being able to have a form's clean method associate errors with a
 particular field is very handy. Being able to do this at the model level
 and then have model forms take advantage of it would bring model forms
 more on par with regular forms.

-- 
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] r16518 - django/trunk/docs/ref/models

[noreply]

Author: kmtracey
Date: 2011-07-05 17:21:32 -0700 (Tue, 05 Jul 2011)
New Revision: 16518

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
s/get/filter in new example of how to use queryset update method: update won't 
work on a model instance.


Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2011-07-05 20:16:08 UTC (rev 
16517)
+++ django/trunk/docs/ref/models/querysets.txt  2011-07-06 00:21:32 UTC (rev 
16518)
@@ -1326,7 +1326,7 @@
 
 ...do this::
 
-Entry.objects.get(id=10).update(comments_on=False)
+Entry.objects.filter(id=10).update(comments_on=False)
 
 Using ``update()`` instead of loading the object into memory also prevents a
 race condition where something might change in your database in the short

-- 
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] #16418: Class based generic DetailView tries to access non-existant _meta field when get_object has been modified to return a ModelForm

[Django]

#16418: Class based generic DetailView tries to access non-existant _meta field
when get_object has been modified to return a ModelForm
-+-
   Reporter:  kd4ttc |  Owner:  kd4ttc
   Type:  Bug| Status:  new
  Milestone: |  Component:  Generic views
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  genericviews
   Triage Stage: |  modelform
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by kd4ttc):

 BTW I thought it was pretty well documented. What other documentation is
 needed? Should I propose a patch? What tests are needed?(this is my first
 bug report)

-- 
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] #16418: Class based generic DetailView tries to access non-existant _meta field when get_object has been modified to return a ModelForm

[Django]

#16418: Class based generic DetailView tries to access non-existant _meta field
when get_object has been modified to return a ModelForm
-+-
   Reporter:  kd4ttc |  Owner:  kd4ttc
   Type:  Bug| Status:  new
  Milestone: |  Component:  Generic views
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  genericviews
   Triage Stage: |  modelform
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by kd4ttc):

 What I did was generate a list of entries with a generic view and then
 want to drill down to review the entries in all the fields. If it needs
 editing there are controls that will then go to a modification page. I
 will be trying out the generic edit views next. A similar bug might be
 there, too.

-- 
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] #3777: Persistent change_list filtering in admin

[Django]

#3777: Persistent change_list filtering in admin
-+-
   Reporter:  matt   |  Owner:  nobody
   | Status:  reopened
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  filter session
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  1  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Let's accept this feature request. If it turns out to be controversial,
 the ticket can be moved to 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-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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
-+-
   Reporter: |  Owner:  nobody
  alexandrul | Status:  reopened
   Type:  New|  Component:  Documentation
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 The warnings also happen with the Makefile. Indeed, it deserves a separate
 ticket. I created #16422.

-- 
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] #16422: Warnings when building the docs in epub format

[Django]

#16422: Warnings when building the docs in epub format
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:
Milestone:   |  Documentation
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
 I guess it's ultra-low priority, but it was reported in the comments of
 #16414:
 {{{

 docs % make epub
 sphinx-build -b epub -d _build/doctrees   . _build/epub
 Making output directory...
 Running Sphinx v1.0.5
 loading pickled environment... not yet created
 building [epub]: targets for 219 source files that are out of date
 updating environment: 219 added, 0 changed, 0 removed
 reading sources... [100%] topics/testing
 looking for now-outdated files... none found
 pickling environment... done
 checking consistency... done
 preparing documents... done
 writing output... [100%] topics/testing
 writing additional files... genindex py-modindex search
 copying images... [100%] internals/_images/djangotickets.png
 copying downloadable files... [100%] ref/contrib/gis
 /create_template_postgis-debian.sh
 copying static files... done
 writing mimetype file...
 writing META-INF/container.xml file...
 writing content.opf file...
 WARNING: unknown mimetype for _downloads/create_template_postgis-1.3.sh,
 ignoring
 WARNING: unknown mimetype for _downloads/create_template_postgis-1.4.sh,
 ignoring
 WARNING: unknown mimetype for _downloads/create_template_postgis-1.5.sh,
 ignoring
 WARNING: unknown mimetype for _downloads/create_template_postgis-
 debian.sh, ignoring
 WARNING: unknown mimetype for _downloads/geodjango_setup.bat, ignoring
 WARNING: unknown mimetype for _static/doctools.js, ignoring
 WARNING: unknown mimetype for _static/jquery.js, ignoring
 WARNING: unknown mimetype for _static/searchtools.js, ignoring
 WARNING: unknown mimetype for _static/underscore.js, ignoring
 writing toc.ncx file...
 writing Django.epub file...
 build succeeded, 9 warnings.

 Build finished. The epub file is in _build/epub.
 }}}

-- 
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] #16395: urlize works with malformed URLs

[Django]

#16395: urlize works with malformed URLs
-+-
   Reporter: |  Owner:  nobody
  BernhardEssl   | Status:  new
   Type: |  Component:  Template system
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * type:  Bug => Cleanup/optimization


-- 
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] #16395: urlize works with malformed URLs

[Django]

#16395: urlize works with malformed URLs
-+-
   Reporter: |  Owner:  nobody
  BernhardEssl   | Status:  new
   Type:  Bug|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_docs:   => 0
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * needs_better_patch:   => 1


Comment:

 Your patch is basically checking that `http://` is followed by a word
 character; could you explain why this is the right thing to do? IMO,
 validation must be implemented correctly or not at all.

 Regarding the patch, I think it would be much clearer to structure the
 code like this:
 {{{
 if middle.startswith('http://') or middle.startswith('https://'):
 # do additional checks, and set url only if the checks pass
 elif ... # unchanged
 }}}

 It's more readable than adding `not middle.startswith('http')` to every
 subsequent condition — since you only added it to the first one, I think
 http:@foo.com will be misinterpreted as an email. (By the way, Trac
 happily turns that into an HTTP link).

-- 
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] #16400: runserver exits without any warnings

[Django]

#16400: runserver exits without any warnings
--+--
   Reporter:  gour|  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  Core (Other)
Version:  1.3 |   Severity:  Normal
 Resolution:  |   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):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Core (Other)


Comment:

 Since we have a segfault, either Django is doing bad things with `ctypes`,
 or it's a bug in Python.

 It might be http://bugs.python.org/issue9812 but I really don't have any
 proof of this.

 Next step: http://wiki.python.org/moin/DebuggingWithGdb

-- 
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] #16417: GeoAdmin support in StackedInline

[Django]

#16417: GeoAdmin support in StackedInline
--+
   Reporter:  martin@…|  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  GIS
Version:  1.3 |   Severity:  Normal
 Resolution:  |   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):

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


Comment:

 Could you provide the minimal steps to reproduce this bug? A stripped down
 version of your `models.py` and `admin.py` should do the job. Thank you.

-- 
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] #16388: django unittest bug

[Django]

#16388: django unittest bug
--+---
   Reporter:  freewave@…  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  needsinfo   |   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
 * resolution:   => needsinfo


Comment:

 It looks like there's an obsolete or invalid version of unittest2
 installed on your machine. Can you determine which version of unittest is
 actually loaded by Django?

 For instance, in `./manage.py shell`, what's the output of:
 {{{
 >>> import unittest2
 >>> unittest2.__file__
 >>> unittest2.__version__
 }}}


 {{{
 >>> import unittest
 >>> unittest.__file__
 >>> unittest.__version__
 }}}

 {{{
 >>> from django.utils import unittest
 >>> unittest.__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] #16388: django unittest bug

[Django]

#16388: django unittest bug
--+---
   Reporter:  freewave@…  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Old description:

> enviroment: python2.7 + django1.3
> with the steps below:
> 1、 django-admin.py startproject myapp
> 2、 cd myapp
> 3、 manage.py startapp foo
> 4、 manage.py test
>
> error occurs:
> File "C:\Python27\lib\site-packages\django\test\simple.py", line 237, in
> setup_test_environment
> unittest.installHandler()
> AttributeError:'module' object has no attribute 'installHandler'
>

> problem?:
> the file “site-packages\django\utils\unittest” contains the code
> try:
> # check the system path first
> from unittest2 import *
> except ImportError:
> if sys.version_info >= (2,7):
> # unittest2 features are native in Python 2.7
> from unittest import *
> else:
> ...
>
> but unittest2 features are native in Python 2.7?

New description:

 enviroment: python2.7 + django1.3
 with the steps below:

 - 1 django-admin.py startproject myapp
 - 2 cd myapp
 - 3 manage.py startapp foo
 - 4 manage.py test

 error occurs:
 {{{
 File "C:\Python27\lib\site-packages\django\test\simple.py", line 237, in
 setup_test_environment
 unittest.installHandler()
 AttributeError:'module' object has no attribute 'installHandler'
 }}}

 problem?:
 the file “site-packages\django\utils\unittest” contains the code
 {{{
 try:
 # check the system path first
 from unittest2 import *
 except ImportError:
 if sys.version_info >= (2,7):
 # unittest2 features are native in Python 2.7
 from unittest import *
 else:
 ...
 }}}
 but unittest2 features are native in Python 2.7?

--

Comment (by aaugustin):

 Fixed formatting, just to be able to read the bug report — please use the
 preview before submitting a bug.

-- 
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] #16369: Remove a misleading comment from the signing documentation

[Django]

#16369: Remove a misleading comment from the signing documentation
-+-
   Reporter:  mitsuhiko  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:  signing
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 The aforementioned documentation is: `docs/topics/signing.txt`

-- 
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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
-+-
   Reporter: |  Owner:  nobody
  alexandrul | Status:  reopened
   Type:  New|  Component:  Documentation
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * stage:  Accepted => Ready for checkin


Comment:

 Using make.bat from the attached 16414.diff with Sphinx 1.0.7:
 * make html: build succeeded.
 * make epub:
 {{{
 copying static files... done
 writing mimetype file...
 writing META-INF/container.xml file...
 writing content.opf file...
 WARNING: unknown mimetype for META-INF\container.xml, ignoring
 WARNING: unknown mimetype for _downloads\create_template_postgis-1.3.sh,
 ignoring
 WARNING: unknown mimetype for _downloads\create_template_postgis-1.4.sh,
 ignoring
 WARNING: unknown mimetype for _downloads\create_template_postgis-1.5.sh,
 ignoring
 WARNING: unknown mimetype for _downloads\create_template_postgis-
 debian.sh, ignoring
 WARNING: unknown mimetype for _downloads\geodjango_setup.bat, ignoring
 WARNING: unknown mimetype for _static\doctools.js, ignoring
 WARNING: unknown mimetype for _static\jquery.js, ignoring
 WARNING: unknown mimetype for _static\searchtools.js, ignoring
 WARNING: unknown mimetype for _static\underscore.js, ignoring
 writing toc.ncx file...
 writing Django.epub file...
 build succeeded, 10 warnings.
 }}}

 Regarding the epub warnings, I guess that's another 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] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1
 * easy:  0 => 1
 * 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.

Re: [Django] #16377: "Conditionally disabling actions" documentation needs updating

[Django]

#16377: "Conditionally disabling actions" documentation needs updating
-+-
   Reporter: |  Owner:  nobody
  pgullekson@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Old description:

> The docs in question are:
> https://docs.djangoproject.com/en/1.3/ref/contrib/admin/actions
> /#conditionally-enabling-or-disabling-actions
>
> The suggestion is to use del actions['delete_selected'], which worked
> fine in Django 1.2. However, because of changes made to
> django.contrib.admin.options:get_actions, in the case that
> IS_POPUP_VAR==True, this del statement will result in an exception. Need
> a try/except or something.

New description:

 The docs in question are:
 https://docs.djangoproject.com/en/1.3/ref/contrib/admin/actions
 /#conditionally-enabling-or-disabling-actions

 The suggestion is to use `del actions['delete_selected']`, which worked
 fine in Django 1.2. However, because of changes made to
 `django.contrib.admin.options.get_actions`, in the case that `IS_POPUP_VAR
 == True`, this del statement will result in an exception. Need a
 try/except or something.

--

Comment:

 Fixed formatting (please use a little bit of wiki syntax and the preview
 to make your reports readable).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16407: Unicode not working for direct SQL INSERT

[Django]

#16407: Unicode not working for direct SQL INSERT
-+-
   Reporter: |  Owner:  nobody
  mashedmeat | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution:  invalid|   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 This is not specific to Django; it's a direct consequence of the DB-API
 (PEP 249, if memory serves).

 The database adapter has no way of knowing which parameters should be
 escaped as table names and which parameters should be escaped as "regular
 parameters" — no magic here.

 You must use string interpolation to insert the table name in the SQL
 query, and parameter substitution for the parameters. I hope your table
 names are not derived from user input :) You may validate them against a
 whitelist or a simple regexp if they're really variable.

-- 
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] #16416: date template tag should support "e" and "o" format character (was: date template tag should support "o" format character)

[Django]

#16416: date template tag should support "e" and "o" format character
---+-
   Reporter:  CarstenF |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Template system
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:  ISO 8601
   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):

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


Comment:

 Here's a list of the differences between what PHP supports and what Django
 supports:

 {{{
 b => added in Django
 B => not implemented in Django
 E => added in Django
 e => not available in Django, added in PHP 5.1.0
 f => added in Django
 I => not implemented in Django
 N => added in Django, added in PHP 5.1.0 with a different meaning
 o => not available in Django, added in PHP 5.1.0
 P => added in Django, added in PHP 5.1.3 with a different meaning
 }}}

 We should implement `e` and `o`, or mention in the docs that they're not
 implemented, like `B` and `I`.

 Another possibility, given the divergence of `N` and `P`, is to drop the
 reference to PHP from 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.

Re: [Django] #16407: Unicode not working for direct SQL INSERT

[Django]

#16407: Unicode not working for direct SQL INSERT
-+-
   Reporter: |  Owner:  nobody
  mashedmeat | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by BernhardEssl):

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


Comment:

 The tablename gets escaped with single quotes, which isn't a correct SQL
 Syntax.

 {{{
 cursor.execute("INSERT INTO %s VALUES (NULL, %s, %s)", ["django_site",
 "foo", "bar"])

 #INSERT INTO 'django_site' VALUES (NULL, 'foo', 'bar')
 }}}

 I'm not sure if this is really a bug.

-- 
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] r16517 - django/trunk/docs/ref/models

[noreply]

Author: adrian
Date: 2011-07-05 13:16:08 -0700 (Tue, 05 Jul 2011)
New Revision: 16517

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Added another bit to the update() queryset docs about avoiding race conditions

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2011-07-05 20:09:00 UTC (rev 
16516)
+++ django/trunk/docs/ref/models/querysets.txt  2011-07-05 20:16:08 UTC (rev 
16517)
@@ -1328,6 +1328,10 @@
 
 Entry.objects.get(id=10).update(comments_on=False)
 
+Using ``update()`` instead of loading the object into memory also prevents a
+race condition where something might change in your database in the short
+period of time between loading the object and calling ``save()``.
+
 Finally, note that the ``update()`` method does an update at the SQL level and,
 thus, does not call any ``save()`` methods on your models, nor does it emit the
 ``pre_save`` or ``post_save`` signals (which are a consequence of calling

-- 
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] r16516 - django/trunk/docs/ref/models

[noreply]

Author: adrian
Date: 2011-07-05 13:09:00 -0700 (Tue, 05 Jul 2011)
New Revision: 16516

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Improved update() docs in querysets.txt

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2011-07-05 14:16:37 UTC (rev 
16515)
+++ django/trunk/docs/ref/models/querysets.txt  2011-07-05 20:09:00 UTC (rev 
16516)
@@ -1278,25 +1278,66 @@
 .. method:: update(**kwargs)
 
 Performs an SQL update query for the specified fields, and returns
-the number of rows affected. The ``update()`` method is applied instantly and
-the only restriction on the :class:`.QuerySet` that is updated is that it can
-only update columns in the model's main table. Filtering based on related
-fields is still possible. You cannot call ``update()`` on a
-:class:`.QuerySet` that has had a slice taken or can otherwise no longer be
-filtered.
+the number of rows affected.
 
-For example, if you wanted to update all the entries in a particular blog
-to use the same headline::
+For example, to turn comments off for all blog entries published in 2010,
+you could do this::
 
->>> b = Blog.objects.get(pk=1)
+>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False)
 
-# Update all the headlines belonging to this Blog.
->>> 
Entry.objects.select_related().filter(blog=b).update(headline='Everything is 
the same')
+(This assumes your ``Entry`` model has fields ``pub_date`` and 
``comments_on``.)
 
-The ``update()`` method does a bulk update and does not call any ``save()``
-methods on your models, nor does it emit the ``pre_save`` or ``post_save``
-signals (which are a consequence of calling ``save()``).
+You can update multiple fields -- there's no limit on how many. For example,
+here we update the ``comments_on`` and ``headline`` fields::
 
+>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False, 
headline='This is old')
+
+The ``update()`` method is applied instantly, and the only restriction on the
+:class:`.QuerySet` that is updated is that it can only update columns in the
+model's main table, not on related models. You can't do this, for example::
+
+>>> Entry.objects.update(blog__name='foo') # Won't work!
+
+Filtering based on related fields is still possible, though::
+
+>>> Entry.objects.filter(blog__id=1).update(comments_on=True)
+
+You cannot call ``update()`` on a :class:`.QuerySet` that has had a slice taken
+or can otherwise no longer be filtered.
+
+The ``update()`` method returns the number of affected rows::
+
+>>> Entry.objects.filter(id=64).update(comments_on=True)
+1
+
+>>> Entry.objects.filter(slug='nonexistent-slug').update(comments_on=True)
+0
+
+>>> Entry.objects.filter(pub_date__year=2010).update(comments_on=False)
+132
+
+If you're just updating a record and don't need to do anything with the model
+object, you should use ``update()`` rather than loading the model object into
+memory. The former is more efficient. For example, instead of doing this::
+
+e = Entry.objects.get(id=10)
+e.comments_on = False
+e.save()
+
+...do this::
+
+Entry.objects.get(id=10).update(comments_on=False)
+
+Finally, note that the ``update()`` method does an update at the SQL level and,
+thus, does not call any ``save()`` methods on your models, nor does it emit the
+``pre_save`` or ``post_save`` signals (which are a consequence of calling
+``save()``). If you want to update a bunch of records for a model that has a
+custom ``save()`` method, loop over them and call ``save()``, like this::
+
+for e in Entry.objects.filter(pub_date__year=2010):
+e.comments_on = False
+e.save()
+
 delete
 ~~
 

-- 
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] #16413: changing settings.LOGIN_URL to end with something different than /login/, causes an error in testing your app

[Django]

#16413: changing settings.LOGIN_URL to end with something different than 
/login/,
causes an error in testing your app
+-
   Reporter:  haras |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.auth
Version:  SVN   |   Severity:  Release blocker
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+-
Changes (by aaugustin):

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


Comment:

 This doesn't happen when you run the test suite because `runtests.py` sets
 `settings.LOGIN_URL = '/accounts/login/'` (line 119). Changing it causes
 12 test failures.

 The 6 failures in `modeltests` and the 5 failures in`regressiontests`
 don't matter, because these tests are only supposed to be run by
 `runtests.py`.

 The failure in `django.contrib.auth.tests` does, because this test may be
 run by `./manage.py test`, and then the value of `settings.LOGIN_URL`
 won't be enforced.

-- 
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] #10863: Email full stack traces like in the debug error pages

[Django]

#10863: Email full stack traces like in the debug error pages
-+-
   Reporter:  boxed  |  Owner:  brodie
   Type: | Status:  closed
  Uncategorized  |  Component:  Core (Other)
  Milestone:  1.3|   Severity:  Normal
Version:  SVN|   Keywords:  stack, errors,
 Resolution:  fixed  |  email
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by Tuttle):

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


Comment:

 Later disabled by default for safety reasons. Related ticket: #15603

 Personally I enable the HTML multipart like this:

 {{{#!python
 LOGGING['handlers']['mail_admins']['include_html'] = True
 }}}

 Only enable if you know what you're doing (when you have safe mail path
 where unauthorized people can't read sensitive content).

-- 
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] #11585: i18n in urls.py

[Django]

#11585: i18n in urls.py
-+-
   Reporter:  digi604|  Owner:  jezdez
   Type:  New| Status:  closed
  feature|  Component:
  Milestone:  1.4|  Internationalization
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 aaugustin):

 Yes, this is #16332, and it's already implemented.

-- 
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] #11585: i18n in urls.py

[Django]

#11585: i18n in urls.py
-+-
   Reporter:  digi604|  Owner:  jezdez
   Type:  New| Status:  closed
  feature|  Component:
  Milestone:  1.4|  Internationalization
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 jakub):

 Thanks for this new feature.

 Are there any plans to include also an i18n-aware version of the `{% url
 %}`  template tag? I know that it will work fine for the current language,
 but when one needs a URL of a page in another language, then the existing
 tag doesn't help. It would be great if there was also an option to get a
 URL of the current page in another language without having to specify it
 or its name as well. I'm aware of `django.views.i18n.set_language()` but a
 link is often needed for search engines to be able to discover the page.

 This is a general problem applying also to `reverse()` but there I suppose
 you can work it around by activating another language, reversing the URL
 and then switching back.


 I'm willing to provide a patch for the template tag  if there is any
 chance for it being included in 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] #16418: Class based generic DetailView tries to access non-existant _meta field when get_object has been modified to return a ModelForm

[Django]

#16418: Class based generic DetailView tries to access non-existant _meta field
when get_object has been modified to return a ModelForm
-+-
   Reporter:  kd4ttc |  Owner:  kd4ttc
   Type:  Bug| Status:  new
  Milestone: |  Component:  Generic views
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  genericviews
   Triage Stage: |  modelform
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by mattmcc):

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


Comment:

 Ignoring whether or not this is a bug for the moment, if the primary
 object of your view is a form, wouldn't it work better to use !CreateView,
 !UpdateView, or your own view that pulls in !ModelFormMixin?

-- 
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] #16420: Windows 7 and Vista support symbolic links

[Django]

#16420: Windows 7 and Vista support symbolic links
-+---
   Reporter:  dpjh70100@…|  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+---
Changes (by ramiro):

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


Comment:

 This had already been proposed in #6739 but a more generic modification
 of the docs was implemented instead.

-- 
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] #16304: Add HTML5 'placeholder' attribute support to form fields.

[Django]

#16304: Add HTML5 'placeholder' attribute support to form fields.
-+-
   Reporter:  rich@… |  Owner:  avenet
   Type:  New| Status:  assigned
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  forms, placeholder,
 Resolution: |  html5
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+-
Changes (by avenet):

 * owner:  nobody => avenet
 * status:  new => assigned


-- 
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] #16421: Serializing TimeField throws Attribute Error

[Django]

#16421: Serializing TimeField throws Attribute Error
--+--
 Reporter:  silent1mezzo  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Database layer (models, ORM)
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+--
 Affects version 1.2.x, 1.3

 Model:
 {{{
 class TestModel(models.Model):
 test_time = models.TimeField()
 }}}

 Stack Trace
 {{{
 File "/home/webdev/web/virtualenvs/polaris/lib/python2.6/site-
 packages/django/core/serializers/__init__.py", line 87, in serialize
 s.serialize(queryset, **options)
   File "/home/webdev/web/virtualenvs/polaris/lib/python2.6/site-
 packages/django/core/serializers/base.py", line 45, in serialize
 self.handle_field(obj, field)
   File "/home/webdev/web/virtualenvs/polaris/lib/python2.6/site-
 packages/django/core/serializers/python.py", line 45, in handle_field
 self._current[field.name] = field.value_to_string(obj)
   File "/home/webdev/web/virtualenvs/polaris/lib/python2.6/site-
 packages/django/db/models/fields/__init__.py", line 1103, in
 value_to_string
 data = val.strftime("%H:%M:%S")
 AttributeError: 'unicode' object has no attribute 'strftime'
 }}}

-- 
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] #16420: Windows 7 and Vista support symbolic links

[Django]

#16420: Windows 7 and Vista support symbolic links
---+---
 Reporter:  dpjh70100@…|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+---
 Page: https://docs.djangoproject.com/en/dev/topics/install/#installing-
 development-version

 It should be noted in point 4, that you can create a symbolic link in
 Windows 7/Vista as well as Unix, using the mklink command (in this
 example, I created a bin directory under my user folder and added it to my
 path):

 {{{
 mklink \Users\CURRENT-USER\bin\django-admin.py WORKING-DIR\django-
 trunk\django\bin\django-admin.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-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] #16378: locmem should use pickle.HIGHEST_PROTOCOL to match memcached et. al.

[Django]

#16378: locmem should use pickle.HIGHEST_PROTOCOL to match memcached et. al.
+-
   Reporter:  PaulM |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:  1.4   |  Component:  Core (Cache system)
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+-
Changes (by rakuco):

 * cc: kubo@… (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] #16411: Test failure after r16510

[Django]

#16411: Test failure after r16510
-+-
   Reporter:  jezdez |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Cache system)
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 The changes of r16510 were rolled back in r16515.

-- 
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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
---+---
   Reporter:  alexandrul   |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+---
Changes (by aaugustin):

 * has_patch:  0 => 1
 * easy:  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-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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
---+---
   Reporter:  alexandrul   |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Documentation
Version:  1.3  |   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|
---+---

Comment (by aaugustin):

 I created a new sphinx project, checked the diff between the generated
 Makefile and Django's Makefile, and applied the same changes to the
 generated make.bat.

 (Un)fortunately, I don't have access to a Windows machine, so I couldn't
 test the script. I'm attaching the diffs between the default files and
 Django's version too.

-- 
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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
---+---
   Reporter:  alexandrul   |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Documentation
Version:  1.3  |   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):

 * stage:  Unreviewed => Accepted


Comment:

 This was already requested in the comments of #13484. The reported was
 asked to create a new ticket, but (s)he never did.

-- 
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] #16133: cannot access documentation django.contrib.admin

[Django]

#16133: cannot access documentation django.contrib.admin
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * ui_ux:   => 0


Comment:

 #16419 was a duplicate.

-- 
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] #16419: Invalid link at site

[Django]

#16419: Invalid link at site
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Djangoproject.com
  Milestone: |  Web site
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   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):

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


Comment:

 Duplicate of #16133.

-- 
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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
--+-
   Reporter:  haras   |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.auth
Version:  SVN |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-

Comment (by haras):

 ''python manage.py test'' in my project root directory

-- 
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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
--+-
   Reporter:  haras   |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.auth
Version:  SVN |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-

Comment (by ramiro):

 What depends on the contrib.sites contrib apps is the contrib.auth.forms
 module. It changed in [13980] but it it already depended on it.

 What tests are you running?

-- 
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] #16373: Django admin templates trigger a DeprecationWarning

[Django]

#16373: Django admin templates trigger a DeprecationWarning
-+-
   Reporter:  slinkp |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by slinkp):

 Thanks. Adding the right context processor & middleware as per the docs
 solved it.  It turns out that the old API is used by
 'django.contrib.auth.context_processors.auth' which was in my
 TEMPLATE_CONTEXT_PROCESSORS.

-- 
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] #8013: Localflavor for Colombia and Ecuador

[Django]

#8013: Localflavor for Colombia and Ecuador
-+-
   Reporter:  ikks   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  Colombia Ecuador
 Resolution: |  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 jezdez):

 * 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] #16419: Invalid link at site

[Django]

#16419: Invalid link at site
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Djangoproject.com
  Milestone: |  Web site
Version:  1.3|   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 BernhardEssl):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 The link works on my local build. I think this is a website problem.

-- 
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] #16419: Invalid link at site

[Django]

#16419: Invalid link at site
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Djangoproject.com Web site
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
 Steps to reproduce:
 * Go to https://docs.djangoproject.com/en/1.3/py-modindex/
 * Click on "django.contrib.admin" (it links to
 https://docs.djangoproject.com/en/1.3/ref/contrib/admin/index)

 Result: I end up at https://docs.djangoproject.com/en/1.3/ref/contrib/adm/
 along with "Page not found" message

-- 
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] #8013: Localflavor for Colombia and Ecuador

[Django]

#8013: Localflavor for Colombia and Ecuador
-+-
   Reporter:  ikks   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  Colombia Ecuador
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by BernhardEssl):

 added whitespace to the choices.

-- 
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] #15316: Filter with isnull=False failing when isnull checked on subclass of FK model

[Django]

#15316: Filter with isnull=False failing when isnull checked on subclass of FK
model
-+-
   Reporter:  zimnyx |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  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 oinopion):

 * cc: tomek@… (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] #16256: More class based views: formsets derived generic views

[Django]

#16256: More class based views: formsets derived generic views
---+---
   Reporter:  rasca|  Owner:  rasca
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by kd4ttc):

 See ticket 16418. The addition of a generic view for another object type
 should just be done by Subclassing the generic view and then redefining
 get_object() to return the  new object. The ticket 16418 points out a
 small bug in the approach, but a simple workaround is available until it
 gets fixed.

-- 
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] #16418: Class based generic DetailView tries to access non-existant _meta field when get_object has been modified to return a ModelForm

[Django]

#16418: Class based generic DetailView tries to access non-existant _meta field
when get_object has been modified to return a ModelForm
+---
 Reporter:  kd4ttc  |  Owner:  kd4ttc
 Type:  Bug | Status:  new
Milestone:  |  Component:  Generic views
  Version:  1.3 |   Severity:  Normal
 Keywords:  genericviews modelform  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 = Summary =
  I used DetailView and subclassed it, then modified get_object to return a
 ModelForm instance. When it executes an eeror message is generated due to
 the Meta class in ModelForm clashing with the expected Meta attributes in
 the usual object that is passed.  This was initially posted to
 stackoverflow http://stackoverflow.com/q/6564068/820321 where the
 formatting is pleasant to read. This is my first bug report, so the
 formatting of the bug report may not be that good. Apologies in advance.

 = Report Details =
 I've been impressed how rapidly a functional website can go together with
 generic views in the tutorials. Also, the workflow for form processing is
 nice. I used the ModelForm helper class to create a form from a model I
 made and was delighted to see that so much functionality came together.
 When I used the generic list_detail.object_detail I was disappointed that
 all that I could display were fields individually. I knew the ModelForm
 class contained information for rendering, so I wanted to use the
 ModelForm with a generic view.

 I was asking around on stackoverflow to get some direction, and appreciate
 the answers and comments from several posters. I've figured out how to get
 this to work, but there is a bug in DetailView. The solution includes a
 workaround.

 To use a ModelView with the generic view and get all the fields to render
 automatically the following works:

 Create a project, and in it create application inpatients.

 If you have


 {{{
 # inpatients/models.py

 class Inpatient(models.Model):
 last_name = models.CharField(max_length=30)
 first_name = models.CharField(max_length=30,blank=True)
 address = models.CharField(max_length=50,blank=True)
 city = models.CharField(max_length=60,blank=True)
 state = models.CharField(max_length=30,blank=True)
 DOB = models.DateField(blank=True,null=True)
 notes = models.TextField(blank=True)

 def  __unicode__(self):
 return u'%s, %s %s' % (self.last_name, self.first_name, self.DOB)

 class InpatientForm(ModelForm):
 class Meta:
 model = Inpatient
 }}}

 and

 {{{
 # inpatients/views.py

 from django.http import HttpResponse, HttpResponseRedirect
 from django.shortcuts import render_to_response
 from django.views.generic import DetailView
 from portal.inpatients.models import *

 def formtest(request):
 if request.method == 'POST':
 form = InpatientForm(request.POST)
 if form.is_valid():
 form.save()
 return HttpResponseRedirect('/inpatients')
 else:
 form = InpatientForm()
 return render_to_response("formtest.html", {'form': form})

 class FormDetailView(DetailView):
 model=Inpatient
 context_object_name='inpatient'   # defines the name in the template
 template_name_field='inpatient_list_page.html'

 def get_object(self):
 inpatient=super(FormDetailView,self).get_object()
 form=InpatientForm(instance=inpatient)
 return form

 def get_template_names(self):
 return ['inpatient_list_page.html',]
 }}}
 and

 {{{
 #urls.py

 from django.conf.urls.defaults import patterns, include, url
 from django.views.generic import ListView
 from portal.inpatients.models import Inpatient, InpatientForm
 from portal.inpatients.views import FormDetailView

 urlpatterns = patterns('',
 (r'^formtest/$','portal.inpatients.views.formtest'),
 (r'^inpatients/$', ListView.as_view(
 model=Inpatient, template_name='inpatient_list_page.html')),
 (r'^inpatient-detail/(?P\d+)/$', FormDetailView.as_view()),
 )

 # with a template containing

 {% block content %}
 Inpatients
 
 {% for aninpatient in object_list %}
 
 {{ aninpatient }}, id={{ aninpatient.id }}
 {% endfor %}
 
 {{ inpatient.as_p }}
 {% endblock %}
 # Yeah, kind of hokey. The template is for both the list view and detail
 view.
 # Note how the form is rendered with one line - {{ inpatient.as_p }}
 }}}

 t works. The instructions for using class based generic views lives at
 https://docs.djangoproject.com/en/1.3/topics/class-based-views/
 Instructions there are pretty clear. The key to making things work is to
 redefine get_object. In the documentation under the section "Performing
 ex

[Django] #16417: GeoAdmin support in StackedInline

[Django]

#16417: GeoAdmin support in StackedInline
--+
 Reporter:  martin@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  GIS
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+
 StackedInline doesn't render a Map, although it should.

-- 
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] #16282: CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount fails on MySQL

[Django]

#16282: CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount 
fails
on MySQL
+---
   Reporter:  ojii  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  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 |
+---

Comment (by ramiro):

 One extradata point:

 I see this only when using the MyISAM MySQL storage backend (and using the
 `--pair text.TextTests.test_cookie_date` trick). Inserting prints of
 `connection.queries` show that the SQL queries are:

 {{{
 #!sql
 SELECT `comment_tests_article`.`id`, `comment_tests_article`.`author_id`,
 `comment_tests_article`.`headline` FROM `comment_tests_article` WHERE
 `comment_tests_article`.`id` = 1
 SELECT `django_content_type`.`id`, `django_content_type`.`name`,
 `django_content_type`.`app_label`, `django_content_type`.`model` FROM
 `django_content_type` WHERE (`django_content_type`.`model` = 'article'
 AND `django_content_type`.`app_label` = 'comment_tests' )
 }}}

 The second query is the problematic one.

-- 
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] #15316: Filter with isnull=False failing when isnull checked on subclass of FK model

[Django]

#15316: Filter with isnull=False failing when isnull checked on subclass of FK
model
-+-
   Reporter:  zimnyx |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  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 russellm):

 * needs_better_patch:  0 => 1


Comment:

 Looks good to me -- I'd like to see a couple of minor fixes before marking
 it RFC.

 The current if statement checks "value is True" and "not negate" as two
 separate checks; the patch adds a test to make sure that the "value is
 True" part isn't actually required, but doesn't validate that it also
 isn't required for the negation case. There are essentially 4 cases that
 need to be tested:

  * filter(isnull=True)
  * exclude(isnull=True)
  * filter(isnull=False)
  * exclude(isnull=False)

 It's entirely possible that some of these cases might be checked
 elsewhere, but it doesn't hurt to validate all four just to be certain.

 It would also be good to validate at a stronger level than count -- for
 example, if you get the joins wrong, it's possible that you might be
 validating the existence of a DumbCategory rather than a NamedCategory. It
 would be better to validate against something that clearly identified that
 the right CategoryItem object was being returned, rather than just
 validating that only 1 instance is returned.

 Lastly, I think two nasty ORM bugs is enough to earn you a line in the
 AUTHORS file :-) Feel free to include that change in the updated patch,
 too.

-- 
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] #15255: DB Cache table creation (createcachetable) ignores the DB Router

[Django]

#15255: DB Cache table creation (createcachetable) ignores the DB Router
+-
   Reporter:  zvikico   |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:  1.4   |  Component:  Core (Cache system)
Version:  1.3-beta  |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by jezdez):

 * status:  closed => reopened
 * needs_better_patch:  0 => 1
 * ui_ux:   => 0
 * resolution:  fixed =>
 * stage:  Ready for checkin => Accepted


Comment:

 I rolled back the changes in r16515.

-- 
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] r16515 - in django/trunk: django/contrib/gis/db/backends/spatialite django/core/management/commands django/db/backends tests/regressiontests/cache

[noreply]

Author: jezdez
Date: 2011-07-05 07:16:37 -0700 (Tue, 05 Jul 2011)
New Revision: 16515

Modified:
   django/trunk/django/contrib/gis/db/backends/spatialite/creation.py
   django/trunk/django/core/management/commands/createcachetable.py
   django/trunk/django/db/backends/creation.py
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Rolled back r16510, r16513 and r16514 because it wasn't ready.

Modified: django/trunk/django/contrib/gis/db/backends/spatialite/creation.py
===
--- django/trunk/django/contrib/gis/db/backends/spatialite/creation.py  
2011-07-05 13:56:20 UTC (rev 16514)
+++ django/trunk/django/contrib/gis/db/backends/spatialite/creation.py  
2011-07-05 14:16:37 UTC (rev 16515)
@@ -33,7 +33,9 @@
 for cache_alias in settings.CACHES:
 cache = get_cache(cache_alias)
 if isinstance(cache, BaseDatabaseCache):
-call_command('createcachetable', cache._table, 
database=self.connection.alias)
+from django.db import router
+if router.allow_syncdb(self.connection.alias, 
cache.cache_model_class):
+call_command('createcachetable', cache._table, 
database=self.connection.alias)
 # Get a cursor (even though we don't need one yet). This has
 # the side effect of initializing the test database.
 cursor = self.connection.cursor()

Modified: django/trunk/django/core/management/commands/createcachetable.py
===
--- django/trunk/django/core/management/commands/createcachetable.py
2011-07-05 13:56:20 UTC (rev 16514)
+++ django/trunk/django/core/management/commands/createcachetable.py
2011-07-05 14:16:37 UTC (rev 16515)
@@ -1,8 +1,7 @@
 from optparse import make_option
 
 from django.core.management.base import LabelCommand
-from django.core.cache.backends.db import BaseDatabaseCache
-from django.db import connections, router, transaction, models, 
DEFAULT_DB_ALIAS
+from django.db import connections, transaction, models, DEFAULT_DB_ALIAS
 
 class Command(LabelCommand):
 help = "Creates the table needed to use the SQL cache backend."
@@ -19,11 +18,8 @@
 requires_model_validation = False
 
 def handle_label(self, tablename, **options):
-db = options.get('database', DEFAULT_DB_ALIAS)
-cache = BaseDatabaseCache(tablename, {})
-if not router.allow_syncdb(db, cache.cache_model_class):
-return
-connection = connections[db]
+alias = options.get('database', DEFAULT_DB_ALIAS)
+connection = connections[alias]
 fields = (
 # "key" is a reserved word in MySQL, so use "cache_key" instead.
 models.CharField(name='cache_key', max_length=255, unique=True, 
primary_key=True),
@@ -54,4 +50,4 @@
 curs.execute("\n".join(full_statement))
 for statement in index_output:
 curs.execute(statement)
-transaction.commit_unless_managed(using=db)
+transaction.commit_unless_managed(using=alias)

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2011-07-05 13:56:20 UTC (rev 
16514)
+++ django/trunk/django/db/backends/creation.py 2011-07-05 14:16:37 UTC (rev 
16515)
@@ -261,7 +261,9 @@
 for cache_alias in settings.CACHES:
 cache = get_cache(cache_alias)
 if isinstance(cache, BaseDatabaseCache):
-call_command('createcachetable', cache._table, 
database=self.connection.alias)
+from django.db import router
+if router.allow_syncdb(self.connection.alias, 
cache.cache_model_class):
+call_command('createcachetable', cache._table, 
database=self.connection.alias)
 
 # Get a cursor (even though we don't need one yet). This has
 # the side effect of initializing the test database.

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 13:56:20 UTC 
(rev 16514)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 14:16:37 UTC 
(rev 16515)
@@ -14,11 +14,10 @@
 from django.core import management
 from django.core.cache import get_cache, DEFAULT_CACHE_ALIAS
 from django.core.cache.backends.base import CacheKeyWarning, 
InvalidCacheBackendError
-from django.db import router
 from django.http import HttpResponse, HttpRequest, QueryDict
 from django.middleware.cache import FetchFromCacheMiddleware, 
UpdateCacheMiddleware, CacheMiddleware
-from django.test import RequestFactory, TestCase
-from django.test.utils import get_warnings_state, restore_warnings_state, 
override_settings
+from django.test import RequestFactory
+from django.test.utils import get_warnings_state, restore_war

Re: [Django] #16405: Class based generic DetailView tries to access non-existant _meta field when get_object has been modified to return a ModelForm

[Django]

#16405: Class based generic DetailView tries to access non-existant _meta field
when get_object has been modified to return a ModelForm
-+-
   Reporter: |  Owner:  nobody
  sholland@… | Status:  closed
   Type:  Bug|  Component:  Generic views
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  ModelForm
 Resolution:  duplicate  |  DetailView
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by kd4ttc):

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


-- 
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] r16514 - django/trunk/tests/regressiontests/cache

[noreply]

Author: jezdez
Date: 2011-07-05 06:56:20 -0700 (Tue, 05 Jul 2011)
New Revision: 16514

Modified:
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Removed left over print statement.

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 13:55:14 UTC 
(rev 16513)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 13:56:20 UTC 
(rev 16514)
@@ -771,7 +771,6 @@
 return 'other'
 
 def allow_syncdb(self, db, model):
-print self, db, model
 if model._meta.app_label == 'django_cache':
 return db == 'other'
 

-- 
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] #16411: Test failure after r16510

[Django]

#16411: Test failure after r16510
-+-
   Reporter:  jezdez |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 In [16513]:
 {{{
 #!CommitTicketReference repository="" revision="16513"
 Made cache table test case multidb capable. Refs #16411. Thanks, Russ.
 }}}

-- 
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] r16513 - django/trunk/tests/regressiontests/cache

[noreply]

Author: jezdez
Date: 2011-07-05 06:55:14 -0700 (Tue, 05 Jul 2011)
New Revision: 16513

Modified:
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Made cache table test case multidb capable. Refs #16411. Thanks, Russ.

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 09:40:29 UTC 
(rev 16512)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 13:55:14 UTC 
(rev 16513)
@@ -14,10 +14,10 @@
 from django.core import management
 from django.core.cache import get_cache, DEFAULT_CACHE_ALIAS
 from django.core.cache.backends.base import CacheKeyWarning, 
InvalidCacheBackendError
-from django.db import connections, router
+from django.db import router
 from django.http import HttpResponse, HttpRequest, QueryDict
 from django.middleware.cache import FetchFromCacheMiddleware, 
UpdateCacheMiddleware, CacheMiddleware
-from django.test import RequestFactory
+from django.test import RequestFactory, TestCase
 from django.test.utils import get_warnings_state, restore_warnings_state, 
override_settings
 from django.utils import translation
 from django.utils import unittest
@@ -771,29 +771,32 @@
 return 'other'
 
 def allow_syncdb(self, db, model):
+print self, db, model
 if model._meta.app_label == 'django_cache':
 return db == 'other'
 
-class CreateCacheTableForDBCacheTests(unittest.TestCase):
 
+class CreateCacheTableForDBCacheTests(TestCase):
+multi_db = True
+
 def test_createcachetable_observes_database_router(self):
-with override_settings(DEBUG=True):
-old_routers = router.routers
-try:
-router.routers = [DBCacheRouter()]
-# cache table should not be created on 'default'
+old_routers = router.routers
+try:
+router.routers = [DBCacheRouter()]
+# cache table should not be created on 'default'
+with self.assertNumQueries(0):
 management.call_command('createcachetable', 'cache_table',
 database='default',
 verbosity=0, interactive=False)
-self.assertEqual(len(connections['default'].queries), 0)
-# cache table should be created on 'other'
+# cache table should be created on 'other'
+with self.assertNumQueries(1):
 management.call_command('createcachetable', 'cache_table',
 database='other',
 verbosity=0, interactive=False)
-self.assertNotEqual(len(connections['other'].queries), 0)
-finally:
-router.routers = old_routers
+finally:
+router.routers = old_routers
 
+
 class LocMemCacheTests(unittest.TestCase, BaseCacheTests):
 backend_name = 'django.core.cache.backends.locmem.LocMemCache'
 

-- 
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] #16415: Template block function to strip whitespace from specific chunks

[Django]

#16415: Template block function to strip whitespace from specific chunks
---+-
   Reporter:  foxwhisper   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Template system
Version:  1.3  |   Severity:  Normal
 Resolution:  invalid  |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+-

Comment (by foxwhisper):

 Omg, how the hell did I miss that, I spent a good 20 minutes looking
 around for a solution on djangodocs and google.

 Really sorry :/

-- 
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] #8013: Localflavor for Colombia and Ecuador

[Django]

#8013: Localflavor for Colombia and Ecuador
-+-
   Reporter:  ikks   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  Colombia Ecuador
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 The choices could use a whitespace after the each first item, but other
 than that this looks good.

-- 
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] #16416: date template tag should support "o" format character

[Django]

#16416: date template tag should support "o" format character
-+-
 Reporter:  CarstenF |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Template system
  Version:  1.3  |   Severity:  Normal
 Keywords:  ISO 8601 |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
 The date template tag currently supports the "W" (ISO 8601 week number)
 format character, but not the complementing "o" (ISO 8601 year number
 machting the ISO week number) character.

 Both are described at the documentation that the date template tag is
 referring to:
 http://de2.php.net/manual/en/function.date.php

 A workaround is possible with a custom template tag, returning the result
 of `datetime.strftime("%G")`.

-- 
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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
---+---
   Reporter:  alexandrul   |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by jezdez):

 Ah, alexandrul beat me to 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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
---+---
   Reporter:  alexandrul   |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by jezdez):

 FWIW, usually Sphinx generates a `make.bat` next to the `Makefile` whose
 source code you can see here:
 
https://bitbucket.org/birkenfeld/sphinx/src/8d38013b4043/sphinx/quickstart.py#cl-516

 I could see that shipping that wouldn't be different to us shipping the
 `Makefile`.

-- 
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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
---+---
   Reporter:  alexandrul   |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   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 alexandrul):

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


Comment:

 http://sphinx.pocoo.org/invocation.html#makefile-options

 sphinx-quickstart can generate both the Makefile and the make.bat in a
 single step. I just hope it's an easy task for the one that generated the
 Makefile that is currently provided (which is customized a little bit more
 than usual results of running sphinx-quickstart).

-- 
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] #16415: Template block function to strip whitespace from specific chunks

[Django]

#16415: Template block function to strip whitespace from specific chunks
---+-
   Reporter:  foxwhisper   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Template system
Version:  1.3  |   Severity:  Normal
 Resolution:  invalid  |   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 russellm):

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


Comment:

 Is there something wrong with
 [https://docs.djangoproject.com/en/1.3/ref/templates/builtins/#spaceless
 {% spaceless %}]?

-- 
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] #16415: Template block function to strip whitespace from specific chunks

[Django]

#16415: Template block function to strip whitespace from specific chunks
-+-
 Reporter:  foxwhisper   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Template system
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
 Take the following example:
 {{{
 
 
 }}}

 That would be outputted in a horrible format. Instead, it would be nice to
 wrap it in something like {% no_whitespace %} {% end_no_whitespace %},
 which would in turn strip all whitespace from the beginning and the end.

 Any thoughts?

 Cal

-- 
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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
---+---
   Reporter:  alexandrul   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:  wontfix  |   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 russellm):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * type:  Bug => New feature
 * needs_docs:   => 0
 * resolution:   => wontfix


Comment:

 1. The Windows analog of a Makefile isn't a cmd script. It's a Visual
 Studio build file. A CMD file is just a batch script, and Makefiles
 contain significantly more functionality than a simple CMD file would
 allow.
  2. GNU Make is available for Windows. It suffers from the usual problems
 of unix tools ported to Windows (most notably, a painful installation
 process), but it is available.

 Given that the documentation is available online, is readable in raw
 source format, and *can* be compiled on Windows given the appropriate
 tools, I'm going to mark this wontfix. The alternative is for the Django
 core team to take on the task of developing and/or maintaining a build
 script for a platform that none of us use regularly, requiring tools that
 aren't freely available. While we endeavor to support Windows where
 possible, there is a line at which supporting the eccentricities of
 Windows exceeds the benefits to the community, and I'm comfortable saying
 that this change falls on the other side of that line.

-- 
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] #16414: Missing Windows build script for Sphinx

[Django]

#16414: Missing Windows build script for Sphinx
+---
 Reporter:  alexandrul  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Documentation
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 Currently the documentation can be built only with the Makefile script.
 Please add a cmd script for Windows users.

-- 
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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
--+-
   Reporter:  haras   |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.auth
Version:  SVN |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-

Comment (by haras):

 it is fully functional without ''django.contrib.sites'' app,  no errors,
 but this one test fails.

-- 
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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
--+-
   Reporter:  haras   |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.auth
Version:  SVN |   Severity:  Release blocker
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-
Changes (by haras):

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


Comment:

 Creating test database for alias 'default'...
 
..E.
 

 

 

 ..
 ==
 ERROR: test_custom_email_subject
 (django.contrib.auth.tests.forms.PasswordResetFormTest)
 --
 Traceback (most recent call last):
   File "C:\Python27\Lib\site-packages\django\contrib\auth\tests\forms.py",
 line 264, in test_custom_email_subject
 form.save()
   File "C:\Python27\Lib\site-packages\django\contrib\auth\forms.py", line
 138, in save
 current_site = get_current_site(request)
   File "C:\Python27\Lib\site-packages\django\contrib\sites\models.py",
 line 94, in get_current_site
 current_site = RequestSite(request)
   File "C:\Python27\Lib\site-packages\django\contrib\sites\models.py",
 line 74, in __init__
 self.domain = self.name = request.get_host()
 AttributeError: 'NoneType' object has no attribute 'get_host'

 --
 Ran 326 tests in 5.113s

 FAILED (errors=1)
 Destroying test database for alias 'default'...

-- 
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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
--+-
   Reporter:  haras   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.auth
Version:  SVN |   Severity:  Release blocker
 Resolution:  invalid |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-

Comment (by d0ugal):

 Hmm, maybe I'm wrong then. Feel free to re-open but you should provide
 more information including the traceback from the failing 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.

Re: [Django] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
--+-
   Reporter:  haras   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.auth
Version:  SVN |   Severity:  Release blocker
 Resolution:  invalid |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-

Comment (by haras):

 I am not sure, I have been using contrib.auth without contrib.sites for a
 few years now.

-- 
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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in test

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
--+-
   Reporter:  haras   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.auth
Version:  SVN |   Severity:  Release blocker
 Resolution:  invalid |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-
Changes (by d0ugal):

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


Comment:

 While the contrib apps should be optional, they do depend on each other.
 contrib.auth requires contrib.sites.

-- 
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] #16413: changing settings.LOGIN_URL to end with something different than /login/, causes an error in testing your app

[Django]

#16413: changing settings.LOGIN_URL to end with something different than 
/login/,
causes an error in testing your app
---+-
 Reporter:  haras  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  contrib.auth
  Version:  SVN|   Severity:  Release blocker
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+-
 Try changing settings.LOGIN_URL to end with something different than
 /login/ for example to signup or /admin/ (as it is in my case). You'll get
 an error in testing your app
 (django.contrib.auth.tests.views.ChangePasswordTest)

-- 
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] #16412: Disabling an 'django.contrib.sites' app, causes Try disabling an 'django.contrib.sites' app, (which as it is a contrib app, should be an optional), and you'll get an error in tests wi

[Django]

#16412: Disabling an 'django.contrib.sites' app, causes Try disabling an
'django.contrib.sites' app, (which as it is a contrib app, should be an
optional), and you'll get an error in tests with
django.contrib.auth.tests.forms.PasswordResetFormTest
---+-
 Reporter:  haras  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  contrib.auth
  Version:  SVN|   Severity:  Release blocker
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+-
 Try disabling an 'django.contrib.sites' app, (which as it is a contrib
 app, should be an optional), and you'll get an error in tests with
 django.contrib.auth.tests.forms.PasswordResetFormTest

-- 
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] #16404: intcomma & thousand separator

[Django]

#16404: intcomma & thousand separator
-+-
   Reporter:  grepsd@…   |  Owner:  Grepsd
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.humanize
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * needs_better_patch:  0 => 1
 * component:  Template system => contrib.humanize
 * needs_tests:  0 => 1
 * stage:  Design decision needed => 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.

Re: [Django] #16404: intcomma & thousand separator

[Django]

#16404: intcomma & thousand separator
-+-
   Reporter:  grepsd@…   |  Owner:  Grepsd
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by Grepsd):

 * cc: Grepsd (added)
 * owner:  nobody => Grepsd
 * has_patch:  0 => 1
 * version:  1.3 => SVN


-- 
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] #16411: Test failure after r16510

[Django]

#16411: Test failure after r16510
+---
 Reporter:  jezdez  |Owner:  nobody
 Type:  Bug |   Status:  new
Milestone:  |Component:  Core (Cache system)
  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
+---
 http://ci.django-
 
cms.org/job/Django/database=postgres,python=python2.7/101/testReport/regressiontests.cache.tests/CreateCacheTableForDBCacheTests/test_createcachetable_observes_database_router/

 The postgres tests seem to fail after the addition. Ironically they pass
 for me but give a different message locally:

 {{{

 Traceback (most recent call last):
   File "runtests.py", line 332, in 
 failures = django_tests(int(options.verbosity), options.interactive,
 options.failfast, args)
   File "runtests.py", line 199, in django_tests
 failures = test_runner.run_tests(test_labels, extra_tests=extra_tests)
   File "/Users/jezdez/Code/git/django/django/test/simple.py", line 356, in
 run_tests
 self.teardown_databases(old_config)
   File "/Users/jezdez/Code/git/django/django/test/simple.py", line 322, in
 teardown_databases
 connection.creation.destroy_test_db(old_name, self.verbosity)
   File "/Users/jezdez/Code/git/django/django/db/backends/creation.py",
 line 331, in destroy_test_db
 self._destroy_test_db(test_database_name, verbosity)
   File "/Users/jezdez/Code/git/django/django/db/backends/creation.py",
 line 342, in _destroy_test_db
 cursor.execute("DROP DATABASE %s" %
 self.connection.ops.quote_name(test_database_name))
   File
 "/Users/jezdez/Code/git/django/django/db/backends/postgresql_psycopg2/base.py",
 line 44, in execute
 return self.cursor.execute(query, args)
 django.db.utils.DatabaseError: database "test_django_testing" is being
 accessed by other users
 DETAIL:  There are 1 other session(s) using the database.
 }}}

-- 
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] r16512 - django/trunk/tests/regressiontests/cache

[noreply]

Author: jezdez
Date: 2011-07-05 02:40:29 -0700 (Tue, 05 Jul 2011)
New Revision: 16512

Modified:
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Fixed test failure on Postgres that was added in r16510.

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 09:10:58 UTC 
(rev 16511)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 09:40:29 UTC 
(rev 16512)
@@ -2,6 +2,7 @@
 
 # Unit tests for cache framework
 # Uses whatever cache backend is set in the test settings file.
+from __future__ import with_statement
 
 import hashlib
 import os
@@ -775,23 +776,23 @@
 
 class CreateCacheTableForDBCacheTests(unittest.TestCase):
 
-@override_settings(DEBUG=True)
 def test_createcachetable_observes_database_router(self):
-old_routers = router.routers
-try:
-router.routers = [DBCacheRouter()]
-# cache table should not be created on 'default'
-management.call_command('createcachetable', 'cache_table',
-database='default',
-verbosity=0, interactive=False)
-self.assertEqual(len(connections['default'].queries), 0)
-# cache table should be created on 'other'
-management.call_command('createcachetable', 'cache_table',
-database='other',
-verbosity=0, interactive=False)
-self.assertNotEqual(len(connections['other'].queries), 0)
-finally:
-router.routers = old_routers
+with override_settings(DEBUG=True):
+old_routers = router.routers
+try:
+router.routers = [DBCacheRouter()]
+# cache table should not be created on 'default'
+management.call_command('createcachetable', 'cache_table',
+database='default',
+verbosity=0, interactive=False)
+self.assertEqual(len(connections['default'].queries), 0)
+# cache table should be created on 'other'
+management.call_command('createcachetable', 'cache_table',
+database='other',
+verbosity=0, interactive=False)
+self.assertNotEqual(len(connections['other'].queries), 0)
+finally:
+router.routers = old_routers
 
 class LocMemCacheTests(unittest.TestCase, BaseCacheTests):
 backend_name = 'django.core.cache.backends.locmem.LocMemCache'

-- 
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] #16410: Stange trackeback, if try to get a not existing cache...

[Django]

#16410: Stange trackeback, if try to get a not existing cache...
+-
 Reporter:  jedie   |  Owner:  nobody
 Type:  Bug | Status:  closed
Milestone:  |  Component:  Core (Cache system)
  Version:  1.3 |   Severity:  Normal
   Resolution:  fixed   |   Keywords:  cache
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+-
Changes (by jezdez):

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


Comment:

 In [16511]:
 {{{
 #!CommitTicketReference repository="" revision="16511"
 Fixed #16410 -- Fixed get_cache to behave gracefully when given a string
 that can't be split. Thanks, jedie.
 }}}

-- 
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] r16511 - in django/trunk: django/core/cache tests/regressiontests/cache

[noreply]

Author: jezdez
Date: 2011-07-05 02:10:58 -0700 (Tue, 05 Jul 2011)
New Revision: 16511

Modified:
   django/trunk/django/core/cache/__init__.py
   django/trunk/tests/regressiontests/cache/tests.py
Log:
Fixed #16410 -- Fixed get_cache to behave gracefully when given a string that 
can't be split. Thanks, jedie.

Modified: django/trunk/django/core/cache/__init__.py
===
--- django/trunk/django/core/cache/__init__.py  2011-07-04 21:53:17 UTC (rev 
16510)
+++ django/trunk/django/core/cache/__init__.py  2011-07-05 09:10:58 UTC (rev 
16511)
@@ -126,12 +126,12 @@
 location = args.pop('LOCATION', '')
 return backend, location, args
 else:
-# Trying to import the given backend, in case it's a dotted path
-mod_path, cls_name = backend.rsplit('.', 1)
 try:
+# Trying to import the given backend, in case it's a dotted path
+mod_path, cls_name = backend.rsplit('.', 1)
 mod = importlib.import_module(mod_path)
 backend_cls = getattr(mod, cls_name)
-except (AttributeError, ImportError):
+except (AttributeError, ImportError, ValueError):
 raise InvalidCacheBackendError("Could not find backend '%s'" % 
backend)
 location = kwargs.pop('LOCATION', '')
 return backend, location, kwargs

Modified: django/trunk/tests/regressiontests/cache/tests.py
===
--- django/trunk/tests/regressiontests/cache/tests.py   2011-07-04 21:53:17 UTC 
(rev 16510)
+++ django/trunk/tests/regressiontests/cache/tests.py   2011-07-05 09:10:58 UTC 
(rev 16511)
@@ -12,7 +12,7 @@
 from django.conf import settings
 from django.core import management
 from django.core.cache import get_cache, DEFAULT_CACHE_ALIAS
-from django.core.cache.backends.base import CacheKeyWarning
+from django.core.cache.backends.base import CacheKeyWarning, 
InvalidCacheBackendError
 from django.db import connections, router
 from django.http import HttpResponse, HttpRequest, QueryDict
 from django.middleware.cache import FetchFromCacheMiddleware, 
UpdateCacheMiddleware, CacheMiddleware
@@ -938,6 +938,23 @@
 cache.set(key, val)
 self.assertEqual(cache.get(key), val)
 
+
+class GetCacheTests(unittest.TestCase):
+
+def test_simple(self):
+cache = get_cache('locmem://')
+from django.core.cache.backends.locmem import LocMemCache
+self.assertTrue(isinstance(cache, LocMemCache))
+
+from django.core.cache import cache
+self.assertTrue(isinstance(cache, get_cache('default').__class__))
+
+cache = get_cache(
+'django.core.cache.backends.dummy.DummyCache', **{'TIMEOUT': 120})
+self.assertEqual(cache.default_timeout, 120)
+
+self.assertRaises(InvalidCacheBackendError, get_cache, 
'does_not_exist')
+
 class CacheUtils(unittest.TestCase):
 """TestCase for django.utils.cache functions."""
 

-- 
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] #15269: get_cache method should be documented as part of move to CACHES

[Django]

#15269: get_cache method should be documented as part of move to CACHES
---+---
   Reporter:  abdelazer@…  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:  cache
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by jedie):

 * keywords:   => cache


Comment:

 Replying to [comment:5 jezdez]:
 > Replying to [comment:4 jedie]:
 > > Should i open a new ticket for this?
 >
 > Yes, please.

 done -> https://code.djangoproject.com/ticket/16410

-- 
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] #16410: Stange trackeback, if try to get a not existing cache...

[Django]

#16410: Stange trackeback, if try to get a not existing cache...
---+-
 Reporter:  jedie  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Core (Cache system)
  Version:  1.3|   Severity:  Normal
 Keywords:  cache  |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+-
 e.g.:

 {{{
 cache = get_cache('not_existing_cache')
 }}}

 You will get a strange traceback:

 {{{
   File "./django/core/cache/__init__.py", line 173, in get_cache
 backend, location, params = parse_backend_conf(backend, **kwargs)
   File "./django/core/cache/__init__.py", line 131, in parse_backend_conf
 mod_path, cls_name = backend.rsplit('.', 1)
 ValueError: need more than 1 value to unpack
 }}}

-- 
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] #15269: get_cache method should be documented as part of move to CACHES

[Django]

#15269: get_cache method should be documented as part of move to CACHES
---+---
   Reporter:  abdelazer@…  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Milestone:   |  Component:  Documentation
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|
---+---

Comment (by jezdez):

 Replying to [comment:4 jedie]:
 > Before making get_cache() "public" it should IMHO changed a little bit.
 Because try this:
 >
 > {{{
 > cache = get_cache('not_existing_cache')
 > }}}
 >
 > You will get a strange traceback:
 > {{{
 >   File "./django/core/cache/__init__.py", line 173, in get_cache
 > backend, location, params = parse_backend_conf(backend, **kwargs)
 >   File "./django/core/cache/__init__.py", line 131, in
 parse_backend_conf
 > mod_path, cls_name = backend.rsplit('.', 1)
 > ValueError: need more than 1 value to unpack
 > }}}
 >
 > Should i open a new ticket for this?

 Yes, please.

-- 
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] #16409: `defer()` and `only()` don't play nice with `annotate()`

[Django]

#16409: `defer()` and `only()` don't play nice with `annotate()`
-+-
   Reporter:  mrmachine  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  annotate defer only
  Unreviewed |  count
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by mrmachine):

 * needs_better_patch:  1 => 0


Comment:

 Updated patch to include a fix. Hopefully good to go.

-- 
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] #15269: get_cache method should be documented as part of move to CACHES

[Django]

#15269: get_cache method should be documented as part of move to CACHES
---+---
   Reporter:  abdelazer@…  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Milestone:   |  Component:  Documentation
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 jedie):

 * cc: django@… (added)
 * ui_ux:   => 0


Comment:

 Before making get_cache() "public" it should IMHO changed a little bit.
 Because try this:

 {{{
 cache = get_cache('not_existing_cache')
 }}}

 You will get a strange traceback:
 {{{
   File "./django/core/cache/__init__.py", line 173, in get_cache
 backend, location, params = parse_backend_conf(backend, **kwargs)
   File "./django/core/cache/__init__.py", line 131, in parse_backend_conf
 mod_path, cls_name = backend.rsplit('.', 1)
 ValueError: need more than 1 value to unpack
 }}}

 Should i open a new ticket for this?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16409: `defer()` and `only()` don't play nice with `annotate()`

[Django]

#16409: `defer()` and `only()` don't play nice with `annotate()`
-+-
   Reporter:  mrmachine  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  annotate defer only
  Unreviewed |  count
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by mrmachine):

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


Comment:

 Added a patch with a failing test case.

 {{{
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 E
 ==
 ERROR: test_defer (modeltests.defer.tests.DeferTests)
 --
 Traceback (most recent call last):
   File
 "/Users/mrmachine/Subversion/django/tests/modeltests/defer/tests.py", line
 141, in test_defer
 
self.assertEqual(len(Secondary.objects.annotate(Count('primary')).defer('first')),
 1)
   File "/Users/mrmachine/Subversion/django/django/db/models/query.py",
 line 82, in __len__
 self._result_cache = list(self.iterator())
   File "/Users/mrmachine/Subversion/django/django/db/models/query.py",
 line 300, in iterator
 setattr(obj, aggregate, row[i+aggregate_start])
 IndexError: tuple index out of range

 --
 Ran 1 test in 0.120s

 FAILED (errors=1)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

-- 
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] #16409: `defer()` and `only()` don't play nice with `annotate()`

[Django]

#16409: `defer()` and `only()` don't play nice with `annotate()`
-+-
 Reporter:  mrmachine|  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:  1.4  |  Component:  Database layer
  Version:  SVN  |  (models, ORM)
 Keywords:  annotate defer only  |   Severity:  Normal
  count  |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+-
 When adding `defer()` or `only()` to an existing query that used
 `annotate()` to cut out some fields, I started getting IndexError
 exceptions.

 At first, I thought it was due to `aggregate_start` not being reduced by
 the number of deferred fields in `QuerySet.iterator()`, but when I looked
 at the SQL being generated I saw that ALL fields were being dropped from
 the query, except for the annotation. I suspect that even if this is
 fixed, `aggregate_start` will also need to be reduced by the number of
 deferred fields.

 Here's the traceback:

 {{{
 >>> from django.db.models import Count
 >>> from django.contrib.auth.models import *
 >>> from django.contrib.admin.models import *
 >>> User.objects.annotate(Count('logentry'))
 [, , , ,
 , , , ,
 , , , ,
 , , , ,
 , , , , '...(remaining elements truncated)...']
 >>> User.objects.annotate(Count('logentry')).defer('first_name')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/Users/mrmachine/myproject/django/db/models/query.py", line 69, in
 __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "/Users/mrmachine/myproject/django/db/models/query.py", line 84, in
 __len__
 self._result_cache.extend(self._iter)
   File "/Users/mrmachine/myproject/django/db/models/query.py", line 300,
 in iterator
 setattr(obj, aggregate, row[i+aggregate_start])
 IndexError: tuple index out of range
 }}}

 Here's the generated SQL:

 {{{
 >>> str(User.objects.annotate(Count('logentry')).query)
 'SELECT "auth_user"."id", "auth_user"."username",
 "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
 "auth_user"."password", "auth_user"."is_staff", "auth_user"."is_active",
 "auth_user"."is_superuser", "auth_user"."last_login",
 "auth_user"."date_joined", COUNT("django_admin_log"."id") AS
 "logentry__count" FROM "auth_user" LEFT OUTER JOIN "django_admin_log" ON
 ("auth_user"."id" = "django_admin_log"."user_id") GROUP BY
 "auth_user"."id", "auth_user"."username", "auth_user"."first_name",
 "auth_user"."last_name", "auth_user"."email", "auth_user"."password",
 "auth_user"."is_staff", "auth_user"."is_active",
 "auth_user"."is_superuser", "auth_user"."last_login",
 "auth_user"."date_joined"'
 >>>
 str(User.objects.annotate(Count('logentry')).defer('first_name').query)
 'SELECT COUNT("django_admin_log"."id") AS "logentry__count" FROM
 "auth_user" LEFT OUTER JOIN "django_admin_log" ON ("auth_user"."id" =
 "django_admin_log"."user_id") GROUP BY "auth_user"."id",
 "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name",
 "auth_user"."email", "auth_user"."password", "auth_user"."is_staff",
 "auth_user"."is_active", "auth_user"."is_superuser",
 "auth_user"."last_login", "auth_user"."date_joined"'
 }}}

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