Re: [Django] #16047: postgresql_psycopg2 never restores autocommit mode when leaving transaction management

[Django]

#16047: postgresql_psycopg2 never restores autocommit mode when leaving 
transaction
management
-+-
   Reporter:  brodie |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  psycopg2 autocommit
Needs documentation:  0  |  transactions
Patch needs improvement:  0  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  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] #12890: extra() tables included twice do not generate aliases

[Django]

#12890: extra() tables included twice do not generate aliases
-+-
   Reporter:  semenov|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by anonymous):

 * easy:   => 0


Comment:

 I'm still waiting to hear back on this patch...would the core contributors
 respond more quickly to a 1.3 patch?  I'd just like some word on whether
 this will be rolled into the core or not.  Thanks.

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

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

Re: [Django] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
-+-
   Reporter:  robvdl |  Owner:  ramiro
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  File
Version:  1.0|  uploads/storage
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  upload image
Needs documentation:  0  |  lowercase
Patch needs improvement:  0  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by srj55):

 * needs_better_patch:  1 => 0
 * milestone:   => 1.4


Comment:

 Successfully tested the patch from @SmileyChris on Win7

-- 
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] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
-+-
   Reporter:  robvdl |  Owner:  ramiro
   Type:  Bug| Status:  new
  Milestone: |  Component:  File
Version:  1.0|  uploads/storage
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  upload image
Needs documentation:  0  |  lowercase
Patch needs improvement:  1  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by srj55):

 * needs_better_patch:  0 => 1
 * milestone:  1.4 =>


Comment:

 Successfully tested the patch from @SmileyChris on Win7

-- 
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] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
-+-
   Reporter:  robvdl |  Owner:  ramiro
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  File
Version:  1.0|  uploads/storage
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  upload image
Needs documentation:  0  |  lowercase
Patch needs improvement:  0  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by SmileyChris):

 * needs_better_patch:  1 => 0
 * milestone:   => 1.4


-- 
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] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
-+-
   Reporter:  robvdl |  Owner:  ramiro
   Type:  Bug| Status:  new
  Milestone: |  Component:  File
Version:  1.0|  uploads/storage
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  upload image
Needs documentation:  0  |  lowercase
Patch needs improvement:  1  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by SmileyChris):

 * easy:   => 0


Comment:

 For what it's worth, I agree with ramiro that this should be fixed to
 preserve the case.

 I've got a branch with the a new patch here:
 https://github.com/SmileyChris/django/compare/master...8593-safejoin-
 lowercase-on-windows

 I'm ignoring mitsuhiko's comment, as it has nothing to do with image
 uploads on windows.

-- 
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] r16244 - django/branches/releases/1.3.X/docs/howto

[noreply]

Author: ramiro
Date: 2011-05-18 19:51:39 -0700 (Wed, 18 May 2011)
New Revision: 16244

Modified:
   django/branches/releases/1.3.X/docs/howto/static-files.txt
Log:
[1.3.X] Fixed small typos in staticfiles howto document.

Modified: django/branches/releases/1.3.X/docs/howto/static-files.txt
===
--- django/branches/releases/1.3.X/docs/howto/static-files.txt  2011-05-18 
20:35:32 UTC (rev 16243)
+++ django/branches/releases/1.3.X/docs/howto/static-files.txt  2011-05-19 
02:51:39 UTC (rev 16244)
@@ -44,7 +44,7 @@
 
Your project will probably also have static assets that aren't tied to a
particular app. The :setting:`STATICFILES_DIRS` setting is a tuple of
-   filesystem directories to check when loading static files. Iv's a search
+   filesystem directories to check when loading static files. It's a search
path that is by default empty. See the :setting:`STATICFILES_DIRS` docs
how to extend this list of additional paths.
 
@@ -59,7 +59,7 @@
:ref:`staticfiles_urlpatterns` to your
URLconf, you're done with the setup -- your static files will
automatically be served at the default (for
-   :djadmin:`newly created` projectq) :setting:`STATIC_URL`
+   :djadmin:`newly created` projects) :setting:`STATIC_URL`
of ``/static/``.
 
 3. You'll probably need to refer to these files in your templates. The

-- 
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] #16054: Unexpected DB Caching Behaviour with MySQL

[Django]

#16054: Unexpected DB Caching Behaviour with MySQL
-+-
   Reporter: |  Owner:  nobody
  brendoncrawford| 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  |
-+-
Changes (by russellm):

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


Comment:

 This is a normal and expected behavior for certain transaction isolation
 modes. [http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html See
 the MySQL docs on transaction isolation modes] for more details, or ask on
 django-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.

[Django] #16054: Unexpected DB Caching Behaviour with MySQL

[Django]

#16054: Unexpected DB Caching Behaviour with MySQL
+--
 Reporter:  |  Owner:  nobody
  brendoncrawford   | Status:  new
 Type:  Bug |  Component:  Database layer (models, ORM)
Milestone:  |   Severity:  Normal
  Version:  1.3 |   Triage Stage:  Unreviewed
 Keywords:  |  Easy pickings:  0
Has patch:  0   |
+--
 This example demonstrates faulty caching behaviour using Django ORM with
 MySQL...

 {{{
 ## iPython Shell 1
 > from django.contrib.auth.models import User

 ## iPython Shell 2
 > from django.contrib.auth.models import User

 ## iPython Shell 1
 > a = User()
 > a.username = 'foo'
 > a.email = 'f...@localhost.com'
 > a.save()
 > print a.id
 >> 1

 ## iPython Shell 2
 > print User.objects.get(pk=1).id
 >> 1

 ## MySQL Shell 1
 > SELECT id FROM auth_user WHERE id = 1
 >> 1

 ## iPython Shell 1
 > b = User()
 > b.username = 'bar'
 > b.email = 'b...@localhost.com'
 > b.save()
 > print b.id  #2

 ## iPython Shell 2
 > print User.objects.get(pk=2).id
 >> Raises User.DoesNotExist

 ## MySQL Shell 1
 > SELECT id FROM auth_user WHERE id = 2
 >> 2
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16052: MySQL: CharField's with utf8_bin collation return as str, should return as unicode.

[Django]

#16052: MySQL: CharField's with utf8_bin collation return as str, should return 
as
unicode.
-+-
   Reporter: |  Owner:  graham_king
  graham_king| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  mysql utf_bin
   Triage Stage:  Design |  unicode
  decision needed|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by kmtracey):

 * stage:  Unreviewed => Design decision needed


Comment:

 We tried to do something like this before, see r8318 and r8329. You'll
 notice we were trying to specify `FIELD_TYPE.VARCHAR`, not
 `FIELD_TYPE.VAR_STRING` and upon further investigation we found that the
 VARCHAR variant was never in fact returned by the MySQL C API, so the code
 added to attempt to convert to unicode wasn't ever called. The attempt was
 reverted in r8380.

 It was reverted rather than switched to specify VAR_STRING because
 VAR_STRING is also the type reported for a MySQL column with type
 VARBINARY: truly binary data. Attempting to convert truly binary data to
 unicode (assuming utf-8 encoding) could generate an exception or could
 corrupt the data; it didn't seem appropriate to be attempting the
 conversion for all types MySQL reported as VAR_STRING types.

 Now, Django doesn't actually support binary fields (never generates a
 (VAR)BINARY column), but back then there was some hope it might in the
 future. (Though I've not heard any mention of binary field support in a
 while.) However, the ability to pretty easily create/use custom fields
 means there might be people out there with custom fields that use the
 MySQL VARBINARY type...I fear this proposed change would break such
 fields.

 Also note that this deviation from the norm of returning unicode for
 character data is documented in the database notes:
 http://docs.djangoproject.com/en/1.3/ref/databases/#collation-settings.
 If/when we do find a way to safely change the low-level behavior here
 those notes will need to be revised as well.

-- 
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] #9245: Using choices in a mode field forces use of TypedChoiceField in a form field

[Django]

#9245: Using choices in a mode field forces use of TypedChoiceField in a form
field
+--
   Reporter:  Tarken|  Owner:  badri
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  Forms
Version:  1.0   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+--
Changes (by mitar):

 * cc: mmitar@… (added)
 * easy:   => 0


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

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

Re: [Django] #16053: What does Django do for me

[Django]

#16053: What does Django do for me
-+---
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Uncategorized
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
-+---
Changes (by russellm):

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


Comment:

 Please ask this question on the django-users mailing list. The bug tracker
 is, as the name suggests, for tracking bugs, not answering general user
 queries.

-- 
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] #16053: What does Django do for me

[Django]

#16053: What does Django do for me
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+---
 I'm an experienced programmer but new to python.  Trying to understand
 besides template engine feature and MVC modeling what other capabilities
 does Django provide for me?

-- 
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] #13758: MySQLdb utf8_bin and django causes UnicodeDecodeError

[Django]

#13758: MySQLdb utf8_bin and django causes UnicodeDecodeError
-+-
   Reporter: |  Owner:  nobody
  sam.vevang@…   | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  utf8_binMySQLdb
   Triage Stage:  Accepted   |  collation unicode bytestring
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by sam.vevang@…):

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


Comment:

 I cannot reproduce this in 1.3. Marking this as resolved.

-- 
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] #15910: show delete links for all admin inline formset rows

[Django]

#15910: show delete links for all admin inline formset rows
-+-
   Reporter:  Arthur de  |  Owner:  nobody
  Jong | Status:  new
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by Arthur de Jong ):

 * has_patch:  0 => 1


Comment:

 Just added a patch that implements the described functionality. It moves
 the code that adds the delete link from the "add another" link to a loop
 over all inline objects that don't already have an original object (they
 should have a delete checkbox).

 The delete link is also added to the hidden empty row so automatically
 ends up in any dynamically added rows.

 To determine which rows should get a delete link it checks the row for an
 ID of the original inline object. My initial attempt checked for the
 presense of the delete checkbox but that didn't work correctly when the
 formset has the can_delete property set to False.

 It would be a lot simpler by just doing
 {{{#!js
 $(this).not(".has_original").each(
 }}}
 but this class is only assigned to the TabularInline
 formset. An alternative approach would be to add the has_original class
 in
 
[source:django/trunk/django/contrib/admin/templates/admin/edit_inline/stacked.html
 stacked.html] also. The downside of that is that there may be third-party
 inline templates that may not have this class.

 The patch is tested with both TabularInline and StackedInline with
 can_delete set to True and False on the following browsers:
  * Chromium 11.0.696.65 on Debian
  * Iceweasel 3.6.13 on Debian
  * Internet Explorer 8.0.6001.18702 on Windows XP
  * Firefox 3.6.17 on Windows XP

 Also, a few lines down from my modifications I notice that a line is
 indented with spaces instead of tabs. Do you also want me to include the
 tabs in the patch?

 Note that the patch doesn't include the minified 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.

[Changeset] r16243 - django/branches/releases/1.3.X/docs/topics/http

[noreply]

Author: gabrielhurley
Date: 2011-05-18 13:35:32 -0700 (Wed, 18 May 2011)
New Revision: 16243

Modified:
   django/branches/releases/1.3.X/docs/topics/http/shortcuts.txt
Log:


Modified: django/branches/releases/1.3.X/docs/topics/http/shortcuts.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/shortcuts.txt   
2011-05-18 20:33:12 UTC (rev 16242)
+++ django/branches/releases/1.3.X/docs/topics/http/shortcuts.txt   
2011-05-18 20:35:32 UTC (rev 16243)
@@ -89,7 +89,7 @@
 ``render_to_response``
 ==
 
-.. function:: render_to_response(template[, dictionary][, context_instance][, 
mimetype])
+.. function:: render_to_response(template_name[, dictionary][, 
context_instance][, mimetype])
 
Renders a given template with a given context dictionary and returns an
:class:`~django.http.HttpResponse` object with that rendered text.
@@ -97,7 +97,7 @@
 Required arguments
 --
 
-``template``
+``template_name``
 The full name of a template to use or sequence of template names. If a
 sequence is given, the first template that exists will be used. See the
 :ref:`template loader documentation `

-- 
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] #16052: MySQL: CharField's with utf8_bin collation return as str, should return as unicode.

[Django]

#16052: MySQL: CharField's with utf8_bin collation return as str, should return 
as
unicode.
-+-
   Reporter: |  Owner:  graham_king
  graham_king| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  mysql utf_bin
   Triage Stage: |  unicode
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by graham_king):

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


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

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

[noreply]

Author: gabrielhurley
Date: 2011-05-18 13:33:12 -0700 (Wed, 18 May 2011)
New Revision: 16242

Modified:
   django/trunk/docs/topics/http/shortcuts.txt
Log:
Fixed #16036 -- corrected the argument name for render_to_response in the 
reference docs. Thanks to msabramo for the report.


Modified: django/trunk/docs/topics/http/shortcuts.txt
===
--- django/trunk/docs/topics/http/shortcuts.txt 2011-05-18 20:12:15 UTC (rev 
16241)
+++ django/trunk/docs/topics/http/shortcuts.txt 2011-05-18 20:33:12 UTC (rev 
16242)
@@ -89,7 +89,7 @@
 ``render_to_response``
 ==
 
-.. function:: render_to_response(template[, dictionary][, context_instance][, 
mimetype])
+.. function:: render_to_response(template_name[, dictionary][, 
context_instance][, mimetype])
 
Renders a given template with a given context dictionary and returns an
:class:`~django.http.HttpResponse` object with that rendered text.
@@ -97,7 +97,7 @@
 Required arguments
 --
 
-``template``
+``template_name``
 The full name of a template to use or sequence of template names. If a
 sequence is given, the first template that exists will be used. See the
 :ref:`template loader documentation `

-- 
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] #16036: render_to_response lists the wrong argument name

[Django]

#16036: render_to_response lists the wrong argument name
+---
   Reporter:  msabramo  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Documentation
Version:  1.3   |   Severity:  Normal
 Resolution:  fixed |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
+---
Changes (by gabrielhurley):

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


Comment:

 In [16242]:
 {{{
 #!CommitTicketReference repository="" revision="16242"
 Fixed #16036 -- corrected the argument name for render_to_response in the
 reference docs. Thanks to msabramo for the 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.

[Django] #16052: MySQL: CharField's with utf8_bin collation return as str, should return as unicode.

[Django]

#16052: MySQL: CharField's with utf8_bin collation return as str, should return 
as
unicode.
+--
 Reporter:  graham_king |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Database layer (models, ORM)
  Version:  SVN |   Severity:  Normal
 Keywords:  mysql utf_bin   |   Triage Stage:  Unreviewed
  unicode   |  Easy pickings:  0
Has patch:  1   |
+--
 On MySQL, a !CharField with default collation comes out as unicode, but
 with utf8_bin it comes out as str.

 Adding this line into the conversion dictionary (in
 django/db/backends/mysql/base.py) fixes it:

 {{{
  FIELD_TYPE.VAR_STRING: [(None, force_unicode)],

 }}}

 Patch includes two tests in regressiontests/backends/. The full test suite
 passes with this patch applied.

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

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

Re: [Django] #13758: MySQLdb utf8_bin and django causes UnicodeDecodeError

[Django]

#13758: MySQLdb utf8_bin and django causes UnicodeDecodeError
-+-
   Reporter: |  Owner:  nobody
  sam.vevang@…   | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  utf8_binMySQLdb
   Triage Stage:  Accepted   |  collation unicode bytestring
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by graham_king):

 * version:  1.2 => SVN
 * easy:   => 0


Comment:

 I can't reproduce this.

 Using this model (in app 'backends'):

 {{{
 import tempfile
 from django.core.files.storage import FileSystemStorage

 temp_storage_location = tempfile.mkdtemp()
 temp_storage = FileSystemStorage(location=temp_storage_location)

 class Person(models.Model):
 name = models.CharField(max_length=20)
 avatar = models.FileField(storage=temp_storage, upload_to='tests',
 max_length=15)
 }}}

 and running this test:

 {{{
 from django.db import connections

 cur = connections['default'].cursor()
 cur.execute('ALTER TABLE backends_person MODIFY avatar VARCHAR(15)
 CHARACTER SET utf8 COLLATE utf8_bin;')
 cur.close()

 Person.objects.create(name='Django', avatar='汉语/漢語.png')

 p = models.Person.objects.all()[0]
 p.delete()
 }}}

 it works. I also tried uploading a UTF8 named file via the admin and
 deleting it, and again it worked.

 Could you post a failing test, or more specific instructions for
 replicating?

-- 
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] #16031: Custom comment form is incomplete and wrong.

[Django]

#16031: Custom comment form is incomplete and wrong.
-+-
   Reporter:  ddshore@…  |  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:  1
Patch needs improvement:  0  |
-+-
Changes (by gabrielhurley):

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


Old description:

> When viewing the documentation for the django comment framework
> (http://docs.djangoproject.com/en/dev/ref/contrib/comments/) this is the
> example form that is shown:
>

> {% get_comment_form for event as form %}
> 
>   {{ form }}
>   
> 
>  value="Preview">
>   
> 
>
> However, the post button is missing, only the preview button appears, and
> it's class is shown as a post button.   Not sure what the original
> intention was, but it would probably be better to have both buttons in
> the documentation:
>  = "post">
>

>  value = "preview">
>
> or at least correct the class for the preview button to submit-preview
> instead of submit-post.

New description:

 When viewing the documentation for the django comment framework
 (http://docs.djangoproject.com/en/dev/ref/contrib/comments/) this is the
 example form that is shown:

 {{{
 {% get_comment_form for event as form %}
 
   {{ form }}
   
 
 
   
 
 }}}
 However, the post button is missing, only the preview button appears, and
 it's class is shown as a post button.   Not sure what the original
 intention was, but it would probably be better to have both buttons in the
 documentation:
 {{{
 
 
 }}}
 or at least correct the class for the preview button to submit-preview
 instead of submit-post.

--

Comment:

 Agreed. There are definitely some mixed signals in that example. Might as
 well include both buttons for completeness.

 Speaking of "preview" buttons, you might want to use Trac's preview to
 check your code formatting before submitting your ticket next time. ;-)

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

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

Re: [Django] #16044: "Writing views" documentation reference a nonexistent "previous chapter"

[Django]

#16044: "Writing views" documentation reference a nonexistent "previous chapter"
-+-
   Reporter:  aplanas@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  Documentarion
   Triage Stage:  Ready for  |  Has patch:  0
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by gabrielhurley):

 In [16241]:
 {{{
 #!CommitTicketReference repository="" revision="16241"
 [1.3.X] Fixed #16044 -- Corrected a copy-and-paste error in the opening
 paragraph of the views topic guide. Thanks to aplanas for the report and
 suggested wording.

 Backport of [16240] from trunk.
 }}}

-- 
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] r16241 - django/branches/releases/1.3.X/docs/topics/http

[noreply]

Author: gabrielhurley
Date: 2011-05-18 13:12:15 -0700 (Wed, 18 May 2011)
New Revision: 16241

Modified:
   django/branches/releases/1.3.X/docs/topics/http/views.txt
Log:
[1.3.X] Fixed #16044 -- Corrected a copy-and-paste error in the opening 
paragraph of the views topic guide. Thanks to aplanas for the report and 
suggested wording.

Backport of [16240] from trunk.


Modified: django/branches/releases/1.3.X/docs/topics/http/views.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/views.txt   2011-05-18 
20:10:41 UTC (rev 16240)
+++ django/branches/releases/1.3.X/docs/topics/http/views.txt   2011-05-18 
20:12:15 UTC (rev 16241)
@@ -8,9 +8,9 @@
 . . or anything, really. The view itself contains whatever arbitrary logic is
 necessary to return that response. This code can live anywhere you want, as 
long
 as it's on your Python path. There's no other requirement--no "magic," so to
-speak. For the sake of putting the code *somewhere*, let's create a file called
-``views.py`` in the ``mysite`` directory, which you created in the previous
-chapter.
+speak. For the sake of putting the code *somewhere*, the convention is to
+put views in a file called ``views.py``, placed in your project or
+application directory.
 
 A simple view
 =
@@ -47,7 +47,7 @@
   exceptions, but we'll get to those later.)
 
 .. admonition:: Django's Time Zone
-
+
 Django includes a ``TIME_ZONE`` setting that defaults to
 ``America/Chicago``. This probably isn't where you live, so you might want
 to change it in your settings file.

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

[Changeset] r16240 - django/trunk/docs/topics/http

[noreply]

Author: gabrielhurley
Date: 2011-05-18 13:10:41 -0700 (Wed, 18 May 2011)
New Revision: 16240

Modified:
   django/trunk/docs/topics/http/views.txt
Log:
Fixed #16044 -- Corrected a copy-and-paste error in the opening paragraph of 
the views topic guide. Thanks to aplanas for the report and suggested wording.


Modified: django/trunk/docs/topics/http/views.txt
===
--- django/trunk/docs/topics/http/views.txt 2011-05-18 19:39:50 UTC (rev 
16239)
+++ django/trunk/docs/topics/http/views.txt 2011-05-18 20:10:41 UTC (rev 
16240)
@@ -8,9 +8,9 @@
 . . or anything, really. The view itself contains whatever arbitrary logic is
 necessary to return that response. This code can live anywhere you want, as 
long
 as it's on your Python path. There's no other requirement--no "magic," so to
-speak. For the sake of putting the code *somewhere*, let's create a file called
-``views.py`` in the ``mysite`` directory, which you created in the previous
-chapter.
+speak. For the sake of putting the code *somewhere*, the convention is to
+put views in a file called ``views.py``, placed in your project or
+application directory.
 
 A simple view
 =
@@ -47,7 +47,7 @@
   exceptions, but we'll get to those later.)
 
 .. admonition:: Django's Time Zone
-
+
 Django includes a ``TIME_ZONE`` setting that defaults to
 ``America/Chicago``. This probably isn't where you live, so you might want
 to change it in your settings file.

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

Re: [Django] #16044: "Writing views" documentation reference a nonexistent "previous chapter"

[Django]

#16044: "Writing views" documentation reference a nonexistent "previous chapter"
-+-
   Reporter:  aplanas@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  Documentarion
   Triage Stage:  Ready for  |  Has patch:  0
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by gabrielhurley):

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


Comment:

 In [16240]:
 {{{
 #!CommitTicketReference repository="" revision="16240"
 Fixed #16044 -- Corrected a copy-and-paste error in the opening paragraph
 of the views topic guide. Thanks to aplanas for the report and suggested
 wording.
 }}}

-- 
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] r16239 - django/trunk/docs/topics

[noreply]

Author: gabrielhurley
Date: 2011-05-18 12:39:50 -0700 (Wed, 18 May 2011)
New Revision: 16239

Modified:
   django/trunk/docs/topics/testing.txt
Log:
Correcting a typo and minor grammatical issues from [16237].


Modified: django/trunk/docs/topics/testing.txt
===
--- django/trunk/docs/topics/testing.txt2011-05-18 12:30:22 UTC (rev 
16238)
+++ django/trunk/docs/topics/testing.txt2011-05-18 19:39:50 UTC (rev 
16239)
@@ -1385,7 +1385,7 @@
 response = self.client.get('/sekrit/')
 self.assertRedirects(response, '/accounts/login/?next=/sekrit/')
 
-# Then override the LOGING_URL setting
+# Then override the LOGIN_URL setting
 with self.settings(LOGIN_URL='/other/login/'):
 response = self.client.get('/sekrit/')
 self.assertRedirects(response, '/other/login/?next=/sekrit/')
@@ -1438,10 +1438,10 @@
 .. note::
 
 When overriding settings make sure to also handle the cases in which
-Django or your app's code use a cache or another feature that retain
+Django or your app's code uses a cache or similar feature that retains
 state even if the setting is changed. Django provides the
 :data:`django.test.signals.setting_changed` signal to connect cleanup
-and other state resetting callbacks to.
+and other state-resetting callbacks to.
 
 .. _`Python context manager`: http://www.python.org/dev/peps/pep-0343/
 .. _`decorator`: http://www.python.org/dev/peps/pep-0318/

-- 
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] #16051: Misleading information in Writing your first Django app, part 3

[Django]

#16051: Misleading information in Writing your first Django app, part 3
-+-
   Reporter: |  Owner:  ShawnMilo
  felix.morency@…| Status:  new
   Type:  New|  Component:  Djangoproject.com
  feature|  Web site
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by ShawnMilo):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * owner:  nobody => ShawnMilo
 * needs_docs:   => 0
 * has_patch:  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] #11027: Storage backends should know about the max_length attribute of the FileFields

[Django]

#11027: Storage backends should know about the max_length attribute of the
FileFields
+--
   Reporter:  apollo13  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:  1.3   |  Component:  File uploads/storage
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
+--
Changes (by carljm):

 * type:  New feature => Bug
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 Marking this as a bug, since #15247 makes it clear that's what it is.
 Discussed briefly with jezdez on IRC and concluded that the fix proposed
 here probably is the right one, adding a max_length argument to the
 get_valid_name method of storage classes. Unfortunately, this is backwards
 incompatible, and it won't just break code that was relying on buggy
 behavior, it will break all custom storage backends. So it requires a
 deprecation path, and during the deprecation period that will require
 introspecting the get_valid_name method to see whether it accepts the
 valid_name argument (or trying with, catching the error, and then trying
 without).

 Either one of those is kind of ugly, but the alternative is to introduce a
 new method, like "get_valid_name_with_max_length". That makes the
 deprecation-period code a bit nicer, but then we're stuck with the longer
 method name for good. Probably better to take the short-term hit.

-- 
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] #16051: Misleading information in Writing your first Django app, part 3

[Django]

#16051: Misleading information in Writing your first Django app, part 3
-+
 Reporter:  felix.morency@…  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Djangoproject.com Web site
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+
 Go to: https://docs.djangoproject.com/en/1.3/intro/tutorial03/

 Locate the line saying "Your polls.urls file should now look like this:"

 This information is misleading since the file really is "polls/urls.py".
 Someone on the #django IRC channel pointed out that "polls.urls" is a
 Python module, not a file. This is a Python specific notation nowhere
 mentioned in the tutorial. A note should be written concerning this
 information for users like me that are not familiar with Django nor
 Python. I think it is not a good idea to assume that Django users are
 familiar with Python, especially for a beginner tutorial.

-- 
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] #15247: FileField has max_length=100 but filestorage may return something way longer

[Django]

#15247: FileField has max_length=100 but filestorage may return something way
longer
-+-
   Reporter:  hvdklauw   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  File
Version:  SVN|  uploads/storage
 Resolution:  duplicate  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by carljm):

 * status:  reopened => closed
 * type:  Uncategorized => Bug
 * 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.

Re: [Django] #15247: FileField has max_length=100 but filestorage may return something way longer

[Django]

#15247: FileField has max_length=100 but filestorage may return something way
longer
-+-
   Reporter:  hvdklauw   |  Owner:  nobody
   Type: | Status:  reopened
  Uncategorized  |  Component:  File
  Milestone: |  uploads/storage
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
-+-
Changes (by carljm):

 * status:  closed => reopened
 * type:   => Uncategorized
 * resolution:  fixed =>
 * severity:   => Normal
 * easy:   => 0


Comment:

 Reopening just to re-close as duplicate of #11027. Sorry for the noise,
 but it's confusing for this to be labeled "fixed" in big letters at the
 top of the Trac page, when it is not 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.

Re: [Django] #11240: Compilemessages fails if a % character is at certain places in the .po file

[Django]

#11240: Compilemessages fails if a % character is at certain places in the .po 
file
+--
   Reporter:  tback |  Owner:  garcia_marc
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  Translations
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
+--
Changes (by kikko):

 * cc: kikko (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] #16034: get_field_display: Django needs a filter to allow get_field_display for a dynamic field

[Django]

#16034: get_field_display: Django needs a filter to allow get_field_display for 
a
dynamic field
---+-
   Reporter:  thepapermen  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Template system
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
---+-
Changes (by maraujop):

 * cc: maraujop (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] #16049: Make runserver reuse listening socket

[Django]

#16049: Make runserver reuse listening socket
-+-
   Reporter:  dready |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
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
-+-

Comment (by dready):

 Yeah I was planning to specifically test for win32, use {{{hasattr(socket,
 "fromfd")}}} or try-except, then disable the function accordingly. Ugly,
 but I can't think of a better way.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16049: Make runserver reuse listening socket

[Django]

#16049: Make runserver reuse listening socket
-+-
   Reporter:  dready |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
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
-+-

Comment (by ed@…):

 Windows users don't have socked.fromfd() method which is used in the
 version of django-pserver. - ed

-- 
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] #16050: media directory still lives on in /django/contrib/admin

[Django]

#16050: media directory still lives on in /django/contrib/admin
-+-
   Reporter:  EvilDMP|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.admin
  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  |
-+-
Changes (by jezdez):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16050: media directory still lives on in /django/contrib/admin

[Django]

#16050: media directory still lives on in /django/contrib/admin
--+---
 Reporter:  EvilDMP   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  contrib.admin
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
--+---
 Shouldn't that go into /static now?

 If it does,
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/staticfiles/storage.py#L47
 won't be required any longer.

-- 
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] #8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a kwargs exclude

[Django]

#8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a
kwargs exclude
-+-
   Reporter:  seanl  |  Owner:  jkocherhans
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.0|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by julien):

 Thanks Jannis. I don't think it needs a release note. The removed lines
 were actually useless. If `exclude` is passed via `get_form()`'s kwargs,
 then it is first combined to `ModelAdmin.exclude` but a bit further it
 overrides it anyway via `defaults.update(kwargs)`.

 The provided tests verify the current behaviour and they pass whether
 those two lines are present or not. This is basically just cleaning up
 some stale code. No one could have possibly relied on a different
 behaviour.

-- 
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] #897: Bi-Directional ManyToMany in Admin

[Django]

#897: Bi-Directional ManyToMany in Admin
---+---
   Reporter:  anonymous|  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:   |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Changes (by CarstenF):

 * cc: carsten.fuchs@… (added)
 * easy:   => 0


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

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

Re: [Django] #14288: Template filter: linebreaksbr doesn't normalize newlines

[Django]

#14288: Template filter: linebreaksbr doesn't normalize newlines
+-
   Reporter:  michiel_1981  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-
Changes (by julien):

 * needs_better_patch:  1 => 0


Comment:

 Thank you, Jannis. I took the chance to make
 `django.utils.html.linebreaks` use it as well.

-- 
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] #8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a kwargs exclude

[Django]

#8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a
kwargs exclude
-+-
   Reporter:  seanl  |  Owner:  jkocherhans
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.0|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by jezdez):

 Actually, the test case could probably be split in two methods for further
 isolation.

-- 
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] #14288: Template filter: linebreaksbr doesn't normalize newlines

[Django]

#14288: Template filter: linebreaksbr doesn't normalize newlines
+-
   Reporter:  michiel_1981  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+-
Changes (by jezdez):

 * needs_better_patch:  0 => 1


Comment:

 Please use the utility `django.utils.text.normalize_newlines` to do 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] #8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a kwargs exclude

[Django]

#8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a
kwargs exclude
-+-
   Reporter:  seanl  |  Owner:  jkocherhans
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.0|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * stage:  Accepted => Ready for checkin


Comment:

 LGTM, although it needs a release note addition.

-- 
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] r16238 - django/trunk/tests/regressiontests/settings_tests

[noreply]

Author: jezdez
Date: 2011-05-18 05:30:22 -0700 (Wed, 18 May 2011)
New Revision: 16238

Modified:
   django/trunk/tests/regressiontests/settings_tests/tests.py
Log:
Removed a settings test introduced in r16237 that didn't run on Python < 2.6 
due to a SyntaxError raise regarding the class decorators. Thanks for the hint, 
Julien.

Modified: django/trunk/tests/regressiontests/settings_tests/tests.py
===
--- django/trunk/tests/regressiontests/settings_tests/tests.py  2011-05-18 
12:08:53 UTC (rev 16237)
+++ django/trunk/tests/regressiontests/settings_tests/tests.py  2011-05-18 
12:30:22 UTC (rev 16238)
@@ -63,15 +63,6 @@
 self.assertEqual(DecoratedSettingGetter().test, 'override')
 self.assertRaises(AttributeError, getattr, settings, 'TEST')
 
-@skipIf(sys.version_info[:2] < (2, 6), "Python version is lower than 2.6")
-def test_new_class_decorator(self):
-self.assertEqual(SettingGetter().test, 'undefined')
-@override_settings(TEST='override')
-class DecoratedSettingGetter(SettingGetter):
-pass
-self.assertEqual(DecoratedSettingGetter().test, 'override')
-self.assertRaises(AttributeError, getattr, settings, 'TEST')
-
 def test_signal_callback_context_manager(self):
 self.assertRaises(AttributeError, getattr, settings, 'TEST')
 with self.settings(TEST='override'):

-- 
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] r16237 - in django/trunk: django/test docs/ref docs/topics tests/regressiontests/mail tests/regressiontests/settings_tests

[noreply]

Author: jezdez
Date: 2011-05-18 05:08:53 -0700 (Wed, 18 May 2011)
New Revision: 16237

Modified:
   django/trunk/django/test/signals.py
   django/trunk/django/test/testcases.py
   django/trunk/django/test/utils.py
   django/trunk/docs/ref/signals.txt
   django/trunk/docs/topics/testing.txt
   django/trunk/tests/regressiontests/mail/tests.py
   django/trunk/tests/regressiontests/settings_tests/tests.py
Log:
Fixed #15561 -- Extended test setting override code added in r16165 with a 
decorator and a signal for setting changes.

Modified: django/trunk/django/test/signals.py
===
--- django/trunk/django/test/signals.py 2011-05-18 09:52:44 UTC (rev 16236)
+++ django/trunk/django/test/signals.py 2011-05-18 12:08:53 UTC (rev 16237)
@@ -1,3 +1,5 @@
 from django.dispatch import Signal
 
 template_rendered = Signal(providing_args=["template", "context"])
+
+setting_changed = Signal(providing_args=["setting", "value"])

Modified: django/trunk/django/test/testcases.py
===
--- django/trunk/django/test/testcases.py   2011-05-18 09:52:44 UTC (rev 
16236)
+++ django/trunk/django/test/testcases.py   2011-05-18 12:08:53 UTC (rev 
16237)
@@ -2,7 +2,6 @@
 
 import re
 import sys
-from contextlib import contextmanager
 from functools import wraps
 from urlparse import urlsplit, urlunsplit
 from xml.dom.minidom import parseString, Node
@@ -17,7 +16,7 @@
 from django.http import QueryDict
 from django.test import _doctest as doctest
 from django.test.client import Client
-from django.test.utils import get_warnings_state, restore_warnings_state
+from django.test.utils import get_warnings_state, restore_warnings_state, 
override_settings
 from django.utils import simplejson, unittest as ut2
 from django.utils.encoding import smart_str
 
@@ -342,21 +341,12 @@
 """
 restore_warnings_state(self._warnings_state)
 
-@contextmanager
-def settings(self, **options):
+def settings(self, **kwargs):
 """
 A context manager that temporarily sets a setting and reverts
 back to the original value when exiting the context.
 """
-old_wrapped = settings._wrapped
-override = UserSettingsHolder(settings._wrapped)
-try:
-for key, new_value in options.items():
-setattr(override, key, new_value)
-settings._wrapped = override
-yield
-finally:
-settings._wrapped = old_wrapped
+return override_settings(**kwargs)
 
 def assertRedirects(self, response, expected_url, status_code=302,
 target_status_code=200, host=None, msg_prefix=''):

Modified: django/trunk/django/test/utils.py
===
--- django/trunk/django/test/utils.py   2011-05-18 09:52:44 UTC (rev 16236)
+++ django/trunk/django/test/utils.py   2011-05-18 12:08:53 UTC (rev 16237)
@@ -1,3 +1,5 @@
+from __future__ import with_statement
+
 import sys
 import time
 import os
@@ -2,13 +4,17 @@
 import warnings
-from django.conf import settings
+from django.conf import settings, UserSettingsHolder
 from django.core import mail
 from django.core.mail.backends import locmem
-from django.test import signals
+from django.test.signals import template_rendered, setting_changed
 from django.template import Template, loader, TemplateDoesNotExist
 from django.template.loaders import cached
 from django.utils.translation import deactivate
+from django.utils.functional import wraps
 
-__all__ = ('Approximate', 'ContextList', 'setup_test_environment',
-   'teardown_test_environment', 'get_runner')
 
+__all__ = (
+'Approximate', 'ContextList',  'get_runner', 'override_settings',
+'setup_test_environment', 'teardown_test_environment',
+)
+
 RESTORE_LOADERS_ATTR = '_original_template_source_loaders'
@@ -56,7 +62,7 @@
 An instrumented Template render method, providing a signal
 that can be intercepted by the test system Client
 """
-signals.template_rendered.send(sender=self, template=self, context=context)
+template_rendered.send(sender=self, template=self, context=context)
 return self.nodelist.render(context)
 
 
@@ -160,3 +166,46 @@
 """
 loader.template_source_loaders = getattr(loader, RESTORE_LOADERS_ATTR)
 delattr(loader, RESTORE_LOADERS_ATTR)
+
+
+class OverrideSettingsHolder(UserSettingsHolder):
+"""
+A custom setting holder that sends a signal upon change.
+"""
+def __setattr__(self, name, value):
+UserSettingsHolder.__setattr__(self, name, value)
+setting_changed.send(sender=name, setting=name, value=value)
+
+
+class override_settings(object):
+"""
+Acts as either a decorator, or a context manager. If it's a decorator it
+takes a function and returns a wrapped function. If it's a contextmanager
+it's used with the ``with`` statement. In ei

Re: [Django] #15561: Factorize settings manipulation in tests

[Django]

#15561: Factorize settings manipulation in tests
---+---
   Reporter:  claudep  |  Owner:  lrekucki
   Type:  New feature  | Status:  closed
  Milestone:  1.4  |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:  fixed|   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  0
---+---
Changes (by jezdez):

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


Comment:

 In [16237]:
 {{{
 #!CommitTicketReference repository="" revision="16237"
 Fixed #15561 -- Extended test setting override code added in r16165 with a
 decorator and a signal for setting changes.
 }}}

-- 
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] #7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files

[Django]

#7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files
-+-
   Reporter:  gav|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  management command
   Triage Stage:  Design |  sql sqlall
  decision needed|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by hynek):

 * cc: hs@… (added)
 * easy:   => 0


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

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

Re: [Django] #14614: Dont send Request message when handle_uncaught_exception()

[Django]

#14614: Dont send Request message when handle_uncaught_exception()
---+--
   Reporter:  oaylanc  |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Core (Other)
Version:  1.2  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+--

Comment (by julien):

 Thanks Russell for the feedback. I've submitted another patch with a
 different, more radical, approach. The logic is now done solely in the
 debugging tools. If a view and its request are marked as "sensitive", and
 if `DEBUG` is `False`, then the request info and the frame variables will
 systematically get omitted from the error reports.

 It is still possible to change this logic by overriding the
 `ExceptionReporter.display_sensitive_info()` method and by providing a
 custom logging tool (in lieu of  the default `AdminEmailHandler`).

 This guarantees safety but the tradeoff is that those views are a bit
 harder to debug in production. Maybe there is a sweet spot that could be
 found somewhere between flexibility and safety.

 Let me know if you've got any feedback on this other approach. I'll ponder
 some more and perhaps bring this to the dev-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] #2443: Add IntervalField to database models

[Django]

#2443: Add IntervalField to database models
-+-
   Reporter: |  Owner:  Adys
  ben.tucker@…   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  IntervalField
 Resolution: |  interval duration DurationField
   Triage Stage:  Accepted   |  feature
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by evgenpioneer@…):

 * cc: evgenpioneer@… (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] #16049: Make runserver reuse listening socket

[Django]

#16049: Make runserver reuse listening socket
-+-
   Reporter:  dready |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
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
-+-

Comment (by dready):

 Currently when server crashes, we'll have to Ctrl-C to kill the entire
 process anyway right? It should behave the same way, when the server
 starts up and crashes, there's not much we can do about it. except to kill
 it. I agree though, that we should be aware of side effects, can't say
 I've thought it through. Hopefully we can get some feedback from users of
 django-pserver.

-- 
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] #2443: Add IntervalField to database models

[Django]

#2443: Add IntervalField to database models
-+-
   Reporter: |  Owner:  Adys
  ben.tucker@…   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  IntervalField
 Resolution: |  interval duration DurationField
   Triage Stage:  Accepted   |  feature
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by fckin.spam@…):

 * cc: fckin.spam@… (added)
 * easy:   => 0


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

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

Re: [Django] #16049: Make runserver reuse listening socket

[Django]

#16049: Make runserver reuse listening socket
-+-
   Reporter:  dready |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
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
-+-
Changes (by jezdez):

 * stage:  Unreviewed => Accepted


Comment:

 I like the idea but am not sure what the side effects could be, e.g.
 sockets that are kept open when the server crashes.

-- 
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] r16235 - in django/trunk/docs: howto ref/contrib

[noreply]

Author: jezdez
Date: 2011-05-18 02:51:24 -0700 (Wed, 18 May 2011)
New Revision: 16235

Modified:
   django/trunk/docs/howto/static-files.txt
   django/trunk/docs/ref/contrib/staticfiles.txt
Log:
Fixed #15983 and #16032 -- Another pass over the staticfiles docs. Many thanks 
to Frank Wiles and EvilDMP.

Modified: django/trunk/docs/howto/static-files.txt
===
--- django/trunk/docs/howto/static-files.txt2011-05-17 12:45:02 UTC (rev 
16234)
+++ django/trunk/docs/howto/static-files.txt2011-05-18 09:51:24 UTC (rev 
16235)
@@ -34,85 +34,91 @@
 Using ``django.contrib.staticfiles``
 
 
-Here's the basic usage in a nutshell:
+Basic usage
+---
 
-1. Put your static files somewhere that ``staticfiles`` will find them.
+1. Put your static files somewhere that ``staticfiles`` will find them.
 
-   By default, this means within ``static/`` subdirectories of apps in your
-   :setting:`INSTALLED_APPS`.
+   By default, this means within ``static/`` subdirectories of apps in your
+   :setting:`INSTALLED_APPS`.
 
-   Many projects will also have static assets that aren't tied to a
-   particular app; you can give ``staticfiles`` additional directories to
-   search via the :setting:`STATICFILES_DIRS` setting .
+   Your project will probably also have static assets that aren't tied to a
+   particular app. The :setting:`STATICFILES_DIRS` setting is a tuple of
+   filesystem directories to check when loading static files. It's a search
+   path that is by default empty. See the :setting:`STATICFILES_DIRS` docs
+   how to extend this list of additional paths.
 
-   See the documentation for the :setting:`STATICFILES_FINDERS` setting for
-   details on how ``staticfiles`` finds your files.
+   Additionally, see the documentation for the :setting:`STATICFILES_FINDERS`
+   setting for details on how ``staticfiles`` finds your files.
 
-2. Set the :setting:`STATIC_URL` setting to the URL you want to use
-   for pointing to your static files, e.g.::
+2. Make sure that ``django.contrib.staticfiles`` is included in your
+   :setting:`INSTALLED_APPS`.
 
-   STATIC_URL = '/static/'
+   For :ref:`local development`, if you are using
+   :ref:`runserver` or adding
+   :ref:`staticfiles_urlpatterns` to your
+   URLconf, you're done with the setup -- your static files will
+   automatically be served at the default (for
+   :djadmin:`newly created` projects) :setting:`STATIC_URL`
+   of ``/static/``.
 
-   In projects freshly created with the :djadmin:`startproject`
-   management command this will be preset to ``'/static/'``.
+3. You'll probably need to refer to these files in your templates. The
+   easiest method is to use the included context processor which allows
+   template code like:
 
-3. Make sure that ``django.contrib.staticfiles`` is in your
-   :setting:`INSTALLED_APPS`.
+   .. code-block:: html+django
 
-   For :ref:`local development`, if you are using
-   :ref:`runserver` or adding
-   :ref:`staticfiles_urlpatterns` to your URLconf,
-   you're done! Your static files will automatically be served at the
-   :setting:`STATIC_URL` you specified in step 2.
+   
+When you're ready to move out of local development and deploy your project:
 
-   See :ref:`staticfiles-in-templates` for more details, including an
-   alternate method (using a template tag).
+1. Set the :setting:`STATIC_URL` setting to the public URL for your static
+   files (in most cases, the default value of ``/static/`` is just fine).
 
-When you're ready to move out of local development and deploy your project:
+2. Set the :setting:`STATIC_ROOT` setting to point to the filesystem path
+   you'd like your static files collected to when you use the
+   :djadmin:`collectstatic` management command. For example::
 
-1. Set the :setting:`STATIC_ROOT` setting to point to where you'd like your
-   static files collected to when you use the :djadmin:`collectstatic`
-   management command. For example::
+   STATIC_ROOT = "/home/jacob/projects/mysite.com/sitestatic"
 
-STATIC_ROOT = "/home/jacob/projects/mysite.com/sitestatic"
+3. Run the :djadmin:`collectstatic` management command::
 
-2. Run the :djadmin:`collectstatic` management command::
+   ./manage.py collectstatic
 
-./manage.py collectstatic
+   This'll churn through your static file storage and copy them into the
+   directory given by :setting:`STATIC_ROOT`.
 
-   This'll churn through your static file storage and copy them into the
-   directory given by :setting:`STATIC_ROOT`.
+4. Deploy those files by configuring your webserver of choice to serve the
+   files in :setting:`STATIC_ROOT` at :setting:`STATIC_URL`.
 
-3. Deploy those files by configuring your webserver of choice to serve the
-   files in :setting:`STATIC_ROOT` at :setting:`STA

[Changeset] r16236 - in django/branches/releases/1.3.X/docs: howto ref/contrib

[noreply]

Author: jezdez
Date: 2011-05-18 02:52:44 -0700 (Wed, 18 May 2011)
New Revision: 16236

Modified:
   django/branches/releases/1.3.X/docs/howto/static-files.txt
   django/branches/releases/1.3.X/docs/ref/contrib/staticfiles.txt
Log:
[1.3.X] Fixed #15983 and #16032 -- Another pass over the staticfiles docs. Many 
thanks to Frank Wiles and EvilDMP.

Backport form trunk (r16235).

Modified: django/branches/releases/1.3.X/docs/howto/static-files.txt
===
--- django/branches/releases/1.3.X/docs/howto/static-files.txt  2011-05-18 
09:51:24 UTC (rev 16235)
+++ django/branches/releases/1.3.X/docs/howto/static-files.txt  2011-05-18 
09:52:44 UTC (rev 16236)
@@ -34,85 +34,91 @@
 Using ``django.contrib.staticfiles``
 
 
-Here's the basic usage in a nutshell:
+Basic usage
+---
 
-1. Put your static files somewhere that ``staticfiles`` will find them.
+1. Put your static files somewhere that ``staticfiles`` will find them.
 
-   By default, this means within ``static/`` subdirectories of apps in your
-   :setting:`INSTALLED_APPS`.
+   By default, this means within ``static/`` subdirectories of apps in your
+   :setting:`INSTALLED_APPS`.
 
-   Many projects will also have static assets that aren't tied to a
-   particular app; you can give ``staticfiles`` additional directories to
-   search via the :setting:`STATICFILES_DIRS` setting .
+   Your project will probably also have static assets that aren't tied to a
+   particular app. The :setting:`STATICFILES_DIRS` setting is a tuple of
+   filesystem directories to check when loading static files. Iv's a search
+   path that is by default empty. See the :setting:`STATICFILES_DIRS` docs
+   how to extend this list of additional paths.
 
-   See the documentation for the :setting:`STATICFILES_FINDERS` setting for
-   details on how ``staticfiles`` finds your files.
+   Additionally, see the documentation for the :setting:`STATICFILES_FINDERS`
+   setting for details on how ``staticfiles`` finds your files.
 
-2. Set the :setting:`STATIC_URL` setting to the URL you want to use
-   for pointing to your static files, e.g.::
+2. Make sure that ``django.contrib.staticfiles`` is included in your
+   :setting:`INSTALLED_APPS`.
 
-   STATIC_URL = '/static/'
+   For :ref:`local development`, if you are using
+   :ref:`runserver` or adding
+   :ref:`staticfiles_urlpatterns` to your
+   URLconf, you're done with the setup -- your static files will
+   automatically be served at the default (for
+   :djadmin:`newly created` projectq) :setting:`STATIC_URL`
+   of ``/static/``.
 
-   In projects freshly created with the :djadmin:`startproject`
-   management command this will be preset to ``'/static/'``.
+3. You'll probably need to refer to these files in your templates. The
+   easiest method is to use the included context processor which allows
+   template code like:
 
-3. Make sure that ``django.contrib.staticfiles`` is in your
-   :setting:`INSTALLED_APPS`.
+   .. code-block:: html+django
 
-   For :ref:`local development`, if you are using
-   :ref:`runserver` or adding
-   :ref:`staticfiles_urlpatterns` to your URLconf,
-   you're done! Your static files will automatically be served at the
-   :setting:`STATIC_URL` you specified in step 2.
+   
+When you're ready to move out of local development and deploy your project:
 
-   See :ref:`staticfiles-in-templates` for more details, including an
-   alternate method (using a template tag).
+1. Set the :setting:`STATIC_URL` setting to the public URL for your static
+   files (in most cases, the default value of ``/static/`` is just fine).
 
-When you're ready to move out of local development and deploy your project:
+2. Set the :setting:`STATIC_ROOT` setting to point to the filesystem path
+   you'd like your static files collected to when you use the
+   :djadmin:`collectstatic` management command. For example::
 
-1. Set the :setting:`STATIC_ROOT` setting to point to where you'd like your
-   static files collected to when you use the :djadmin:`collectstatic`
-   management command. For example::
+   STATIC_ROOT = "/home/jacob/projects/mysite.com/sitestatic"
 
-STATIC_ROOT = "/home/jacob/projects/mysite.com/sitestatic"
+3. Run the :djadmin:`collectstatic` management command::
 
-2. Run the :djadmin:`collectstatic` management command::
+   ./manage.py collectstatic
 
-./manage.py collectstatic
+   This'll churn through your static file storage and copy them into the
+   directory given by :setting:`STATIC_ROOT`.
 
-   This'll churn through your static file storage and copy them into the
-   directory given by :setting:`STATIC_ROOT`.
+4. Deploy those files by configuring your webserver of choice to serve the
+   files in :setting:`STATIC_ROOT` at :setting:`STATIC_URL`.
 
-3. Dep

Re: [Django] #16032: Staticfiles doc typo

[Django]

#16032: Staticfiles doc typo
-+-
   Reporter: |  Owner:  nobody
  frankwiles | Status:  closed
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by jezdez):

 In [16236]:
 {{{
 #!CommitTicketReference repository="" revision="16236"
 [1.3.X] Fixed #15983 and #16032 -- Another pass over the staticfiles docs.
 Many thanks to Frank Wiles and EvilDMP.

 Backport form trunk (r16235).
 }}}

-- 
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] #15983: Better explanation of where to put static files

[Django]

#15983: Better explanation of where to put static files
-+-
   Reporter:  EvilDMP|  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by jezdez):

 In [16236]:
 {{{
 #!CommitTicketReference repository="" revision="16236"
 [1.3.X] Fixed #15983 and #16032 -- Another pass over the staticfiles docs.
 Many thanks to Frank Wiles and EvilDMP.

 Backport form trunk (r16235).
 }}}

-- 
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] #15983: Better explanation of where to put static files

[Django]

#15983: Better explanation of where to put static files
-+-
   Reporter:  EvilDMP|  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16235]:
 {{{
 #!CommitTicketReference repository="" revision="16235"
 Fixed #15983 and #16032 -- Another pass over the staticfiles docs. Many
 thanks to Frank Wiles and EvilDMP.
 }}}

-- 
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] #16032: Staticfiles doc typo

[Django]

#16032: Staticfiles doc typo
-+-
   Reporter: |  Owner:  nobody
  frankwiles | Status:  closed
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16235]:
 {{{
 #!CommitTicketReference repository="" revision="16235"
 Fixed #15983 and #16032 -- Another pass over the staticfiles docs. Many
 thanks to Frank Wiles and EvilDMP.
 }}}

-- 
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] #16049: Make runserver reuse listening socket

[Django]

#16049: Make runserver reuse listening socket
-+-
   Reporter:  dready |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by dready):

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


Comment:

 patch coming up..

-- 
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] #16045: Change history admin page not showing custom names for field in change history

[Django]

#16045: Change history admin page not showing custom names for field in change
history
-+---
   Reporter:  jacobwolf@…|  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Uncategorized
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+---
Changes (by ramiro):

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


Comment:

 duplicate of #12952

-- 
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] #16049: Make runserver reuse listening socket

[Django]

#16049: Make runserver reuse listening socket
-+
 Reporter:  dready   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Core (Management commands)
  Version:  SVN  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+
 When using autoreload mode of runserver, there is a small window of time
 between restarts that the port is not bound. This disrupts the workflow
 because one has to wait for the server to come back up before being able
 to reload the browser to see code changes reflected.

 We can reuse the listening socket's file descriptor by having the parent
 create the socket, and passing it to the child (where the real web server
 is run.)

 A proof-of-concept is available on https://github.com/wil/django-pserver

-- 
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] #5579: Trac activation mail is sent from 'webmaster@localhost'

[Django]

#5579: Trac activation mail is sent from 'webmaster@localhost'
-+-
   Reporter:  tback  |  Owner:  anonymous
   Type: | Status:  closed
  Uncategorized  |  Component:  Djangoproject.com
  Milestone: |  Web site
Version: |   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:  activation email
   Triage Stage:  Accepted   |  trac
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by jezdez):

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


Comment:

 I wasn't able to reproduce the 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] #16030: Seperate Admin and User auth table

[Django]

#16030: Seperate Admin and User auth table
-+-
   Reporter:  dfcode |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  admin,auth,database,table,router
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

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


Comment:

 I think this is going to have to be WONTFIX. For every use case where your
 preference makes sense, there will be others where the opposite does. For
 example, when you want to move someone from being a 'non-admin' user to
 being an 'admin' user, it is obviously far more convenient in every way if
 you don't have to move rows from one table to another, but simply flip a
 boolean column.

 I'm not sure what your requirements are, but if you have 'other users' who
 will never need to use the admin, what is stopping you creating your own
 User class, that is routed as you see fit, and using that for
 authorization for those 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.

[Django] #16048: GenericForeignKey always uses a default manager of a related model

[Django]

#16048: GenericForeignKey always uses a default manager of a related model
-+-
 Reporter:  ivan_virabyan|  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:
  Version:  1.3  |  contrib.contenttypes
 Keywords:  genericforeignkey|   Severity:  Normal
  manager|   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+-
 From Django docs:
 By default, Django uses an instance of a "plain" manager class when
 accessing related objects (i.e. choice.poll), not the default manager on
 the related object. This is because Django needs to be able to retrieve
 the related object, even if it would otherwise be filtered out (and hence
 be inaccessible) by the default manager.

 This is true for ForeignKey, but not GenericForeignKey. So I have no
 ability to use custom managers for my models, because they are being
 filtered when I'm accessing related objects.

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