Re: [Django] #16986: Model.clean cannot report errors on individual fields

[Django]

#16986: Model.clean cannot report errors on individual fields
-+-
 Reporter:  davidfstr|Owner:  davidfstr
 Type:  New feature  |   Status:  new
Component:  Forms|  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|UI/UX:  0
-+-
Changes (by carljm):

 * needs_better_patch:  0 => 1


Comment:

 Replying to [comment:13 davidfstr]:
 > Is there any futher action on my part that is preventing this ticket
 from proceeding?

 Nothing preventing, no. You always have the option of finding some other
 community member to review the patch, try it out, and if it seems good to
 them, mark it Ready For Checkin - that'll bump it higher on the commit
 list. But really I just ran short of time the last month or so and never
 got back to this.

 I've done a review now and noticed some new things. I'm not particularly
 concerned about r12402 - if there was an important reason to forbid this,
 it should have been explicitly mentioned in that commit message. It seems
 to me that it simply wasn't considered as a real use case. I am, however,
 concerned about API consistency, and currently there are two ways this
 patch breaks it:

 1. If you can raise `ValidationError` with a dict from `Model.clean()` and
 have `ModelForm` take that up into its error dict, you should be able to
 do the same from `ModelForm.clean()` or `Form.clean()`; in other words,
 regular form validation and model validation should behave the same in
 terms of how `ValidationError` can be used. Having it possible to use a
 dict from the one clean method and not the others is arbitrary and
 confusing.

 2. You can instantiate `ValidationError` with either a single message, or
 a list of messages. If we're going to add instantiation with a dictionary
 as a documented API (which seems fine to me), I think the values in that
 dictionary should similarly be allowed to be either a single message or a
 list of messages, not required to be a list.

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

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

Re: [Django] #4499: integrity error silently failing with postgres and loaddata

[Django]

#4499: integrity error silently failing with postgres and loaddata
-+-
 Reporter:  sandro@… |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  save integrity   |  Needs documentation:  0
  operationalError   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by znick):

 * cc: znick (added)
 * ui_ux:   => 0
 * 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] #16986: Model.clean cannot report errors on individual fields

[Django]

#16986: Model.clean cannot report errors on individual fields
-+-
 Reporter:  davidfstr|Owner:  davidfstr
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by davidfstr):

 Is there any futher action on my part that is preventing this ticket from
 proceeding?

-- 
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] r17193 - django/trunk/tests/regressiontests/i18n/commands

[noreply]

Author: ramiro
Date: 2011-12-10 17:00:41 -0800 (Sat, 10 Dec 2011)
New Revision: 17193

Modified:
   django/trunk/tests/regressiontests/i18n/commands/compilation.py
Log:
Added another `from__future__ import with_statement` missed in r17190.

Modified: django/trunk/tests/regressiontests/i18n/commands/compilation.py
===
--- django/trunk/tests/regressiontests/i18n/commands/compilation.py 
2011-12-11 00:48:26 UTC (rev 17192)
+++ django/trunk/tests/regressiontests/i18n/commands/compilation.py 
2011-12-11 01:00:41 UTC (rev 17193)
@@ -1,3 +1,5 @@
+from __future__ import with_statement
+
 import os
 try:
 from cStringIO import StringIO

-- 
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] r17192 - in django/trunk: django/utils/translation tests/regressiontests/i18n/commands tests/regressiontests/i18n/commands/templates

[noreply]

Author: ramiro
Date: 2011-12-10 16:48:26 -0800 (Sat, 10 Dec 2011)
New Revision: 17192

Modified:
   django/trunk/django/utils/translation/trans_real.py
   django/trunk/tests/regressiontests/i18n/commands/extraction.py
   django/trunk/tests/regressiontests/i18n/commands/templates/test.html
Log:
Made makemessages leave `'%%'` sequences untouched when extracting translatable 
literals from blocktrans template tags.

This makes it consistent with behavior introduced when fixing #11240 in
processing of literal passed to the trans tag to avoid double escaping
(i.e. `''` sequences in resulting PO files.)

Also, cleaned up tests changes from r17190 (removed commented out code and
implemented compatibility with Python 2.5.)

Modified: django/trunk/django/utils/translation/trans_real.py
===
--- django/trunk/django/utils/translation/trans_real.py 2011-12-11 00:09:30 UTC 
(rev 17191)
+++ django/trunk/django/utils/translation/trans_real.py 2011-12-11 00:48:26 UTC 
(rev 17192)
@@ -514,7 +514,7 @@
 else:
 singular.append('%%(%s)s' % t.contents)
 elif t.token_type == TOKEN_TEXT:
-contents = t.contents.replace('%', '%%')
+contents = one_percent_re.sub('%%', t.contents)
 if inplural:
 plural.append(contents)
 else:

Modified: django/trunk/tests/regressiontests/i18n/commands/extraction.py
===
--- django/trunk/tests/regressiontests/i18n/commands/extraction.py  
2011-12-11 00:09:30 UTC (rev 17191)
+++ django/trunk/tests/regressiontests/i18n/commands/extraction.py  
2011-12-11 00:48:26 UTC (rev 17192)
@@ -1,4 +1,6 @@
 # -*- encoding: utf-8 -*-
+from __future__ import with_statement
+
 import os
 import re
 import shutil
@@ -52,7 +54,6 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', locale=LOCALE, verbosity=0)
 self.assertTrue(os.path.exists(self.PO_FILE))
-#po_contents = open(self.PO_FILE, 'r').read()
 with open(self.PO_FILE, 'r') as fp:
 po_contents = fp.read()
 self.assertTrue('#. Translators: This comment should be extracted' 
in po_contents)
@@ -81,7 +82,6 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', locale=LOCALE, verbosity=0)
 self.assertTrue(os.path.exists(self.PO_FILE))
-#po_contents = open(self.PO_FILE, 'r').read()
 with open(self.PO_FILE, 'r') as fp:
 po_contents = fp.read()
 self.assertMsgId('Literal with a percent symbol at the end %%', 
po_contents)
@@ -98,11 +98,11 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', locale=LOCALE, verbosity=0)
 self.assertTrue(os.path.exists(self.PO_FILE))
-#po_contents = open(self.PO_FILE, 'r').read()
 with open(self.PO_FILE, 'r') as fp:
 po_contents = fp.read()
 self.assertMsgId('I think that 100%% is more that 50%% of 
anything.', po_contents)
 self.assertMsgId('I think that 100%% is more that 50%% of 
%(obj)s.', po_contents)
+self.assertMsgId("Blocktrans extraction shouldn't double escape 
this: %%, a=%(a)s", po_contents)
 
 def test_extraction_error(self):
 os.chdir(self.test_dir)
@@ -128,7 +128,6 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', locale=LOCALE, verbosity=0)
 self.assertTrue(os.path.exists(self.PO_FILE))
-#po_contents = open(self.PO_FILE, 'r').read()
 with open(self.PO_FILE, 'r') as fp:
 po_contents = fp.read()
 # {% trans %}
@@ -159,7 +158,6 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', domain='djangojs', 
locale=LOCALE, verbosity=0)
 self.assertTrue(os.path.exists(self.PO_FILE))
-#po_contents = open(self.PO_FILE, 'r').read()
 with open(self.PO_FILE, 'r') as fp:
 po_contents = fp.read()
 self.assertMsgId('This literal should be included.', po_contents)
@@ -183,7 +181,6 @@
 pattern1 = os.path.join('ignore_dir', '*')
 management.call_command('makemessages', locale=LOCALE, verbosity=0, 
ignore_patterns=[pattern1])
 self.assertTrue(os.path.exists(self.PO_FILE))
-#po_contents = open(self.PO_FILE, 'r').read()
 with open(self.PO_FILE, 'r') as fp:
 po_contents = fp.read()
 self.assertMsgId('This literal should be included.', po_contents)
@@ -215,7 +212,6 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', locale=LOCALE, 
verbosity=0, symlinks=True)
 self.assertTrue(os.path.exists(self.PO_FILE))
-#po_contents = open(self.PO_FILE, 'r').read()
 with open(self.PO_FILE, 'r') as fp:
 po_contents = 

[Changeset] r17191 - in django/trunk/tests/regressiontests/i18n/commands/locale: . it it/LC_MESSAGES

[noreply]

Author: ramiro
Date: 2011-12-10 16:09:30 -0800 (Sat, 10 Dec 2011)
New Revision: 17191

Added:
   django/trunk/tests/regressiontests/i18n/commands/locale/it/
   django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/
   
django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/django.mo
   
django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/django.po
Log:
Added files missing from commit [17190]

Added: 
django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/django.mo
===
(Binary files differ)


Property changes on: 
django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/django.mo
___
Added: svn:mime-type
   + application/octet-stream

Added: 
django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/django.po
===
--- 
django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/django.po
(rev 0)
+++ 
django/trunk/tests/regressiontests/i18n/commands/locale/it/LC_MESSAGES/django.po
2011-12-11 00:09:30 UTC (rev 17191)
@@ -0,0 +1,30 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR , YEAR.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2011-12-04 04:59-0600\n"
+"PO-Revision-Date: 2011-12-10 20:29-0300\n"
+"Last-Translator: FULL NAME \n"
+"Language-Team: LANGUAGE \n"
+"Language: it\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=(n != 1)\n"
+
+#, python-format
+msgid "Completed 50%% of all the tasks"
+msgstr "IT translation of Completed 50%% of all the tasks"
+
+#, python-format
+msgid "Looks like a str fmt spec %%s but shouldn't be interpreted as such"
+msgstr "Translation of the above string"
+
+#, python-format
+msgid "Looks like a str fmt spec %% o but shouldn't be interpreted as such"
+msgstr "IT translation contains %% for the above string"

-- 
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] r17190 - in django/trunk: django/utils/translation tests/regressiontests/i18n tests/regressiontests/i18n/commands tests/regressiontests/i18n/commands/locale tests/regressiontests/i18n/com

[noreply]

Author: ramiro
Date: 2011-12-10 16:07:06 -0800 (Sat, 10 Dec 2011)
New Revision: 17190

Added:
   django/trunk/tests/regressiontests/i18n/commands/locale/fr/
   django/trunk/tests/regressiontests/i18n/commands/locale/fr/LC_MESSAGES/
   
django/trunk/tests/regressiontests/i18n/commands/locale/fr/LC_MESSAGES/django.po
Modified:
   django/trunk/django/utils/translation/trans_real.py
   django/trunk/tests/regressiontests/i18n/commands/compilation.py
   django/trunk/tests/regressiontests/i18n/commands/extraction.py
   django/trunk/tests/regressiontests/i18n/commands/templates/test.html
   django/trunk/tests/regressiontests/i18n/tests.py
Log:
Fixed #11240 -- Made makemessages i18n command escape % symbols in literals 
passed to the trans tag.

This avoids problems with unintended automatic detection, marking and
validation of Python string formatting specifiers performed by
xgettext(1)/msgfmt(1) that stem from the fact that under the hood makemessages
converts templates to Python code before passing them to xgettext.

This also makes it consistent with its behavior on literals passed to the
blocktrans tag.

Thanks Jannis and claude for reviewing and feedback.

Modified: django/trunk/django/utils/translation/trans_real.py
===
--- django/trunk/django/utils/translation/trans_real.py 2011-12-09 23:16:56 UTC 
(rev 17189)
+++ django/trunk/django/utils/translation/trans_real.py 2011-12-11 00:07:06 UTC 
(rev 17190)
@@ -439,6 +439,7 @@
 endblock_re = re.compile(r"""^\s*endblocktrans$""")
 plural_re = re.compile(r"""^\s*plural$""")
 constant_re = re.compile(r"""_\(((?:".*?")|(?:'.*?'))\)""")
+one_percent_re = re.compile(r"""(?http://example.com;, po_contents)
-self.assertMsgId("String", po_contents)
-self.assertMsgId("/* but this one will be too */ 'cause there is no 
way of telling...", po_contents)
-self.assertMsgId("foo", po_contents)
-self.assertMsgId("bar", po_contents)
-self.assertMsgId("baz", po_contents)
-self.assertMsgId("quz", po_contents)
-self.assertMsgId("foobar", po_contents)
+#po_contents = open(self.PO_FILE, 'r').read()
+with open(self.PO_FILE, 'r') as fp:
+po_contents = fp.read()
+self.assertMsgId('This literal should be included.', po_contents)
+self.assertMsgId('This one as well.', po_contents)
+self.assertMsgId(r'He said, \"hello\".', po_contents)
+self.assertMsgId("o", po_contents)
+self.assertMsgId("TEXT", po_contents)
+self.assertMsgId("It's at http://example.com;, po_contents)
+self.assertMsgId("String", po_contents)
+self.assertMsgId("/* but this one will be too */ 'cause there is 
no way of telling...", po_contents)
+self.assertMsgId("foo", po_contents)
+self.assertMsgId("bar", po_contents)
+self.assertMsgId("baz", po_contents)
+self.assertMsgId("quz", po_contents)
+self.assertMsgId("foobar", po_contents)
 
 class IgnoredExtractorTests(ExtractorTests):
 
@@ -154,9 +183,11 @@
 pattern1 = os.path.join('ignore_dir', '*')
 management.call_command('makemessages', locale=LOCALE, verbosity=0, 
ignore_patterns=[pattern1])
 self.assertTrue(os.path.exists(self.PO_FILE))
-po_contents = open(self.PO_FILE, 'r').read()
-self.assertMsgId('This literal should be included.', po_contents)
-self.assertNotMsgId('This should be ignored.', po_contents)
+#po_contents = open(self.PO_FILE, 'r').read()
+with open(self.PO_FILE, 'r') as fp:
+po_contents = fp.read()
+self.assertMsgId('This literal should be included.', po_contents)
+self.assertNotMsgId('This should be ignored.', po_contents)
 
 
 class SymlinkExtractorTests(ExtractorTests):
@@ -184,9 +215,11 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', locale=LOCALE, 
verbosity=0, symlinks=True)
 self.assertTrue(os.path.exists(self.PO_FILE))
-po_contents = open(self.PO_FILE, 'r').read()
-self.assertMsgId('This literal should be included.', po_contents)
-self.assertTrue('templates_symlinked/test.html' in po_contents)
+#po_contents = open(self.PO_FILE, 'r').read()
+with open(self.PO_FILE, 'r') as fp:
+po_contents = fp.read()
+self.assertMsgId('This literal should be included.', 
po_contents)
+self.assertTrue('templates_symlinked/test.html' in po_contents)
 
 
 class CopyPluralFormsExtractorTests(ExtractorTests):
@@ -195,8 +228,10 @@
 os.chdir(self.test_dir)
 management.call_command('makemessages', locale=LOCALE, verbosity=0)
 self.assertTrue(os.path.exists(self.PO_FILE))
-po_contents = open(self.PO_FILE, 'r').read()
-self.assertTrue('Plural-Forms: nplurals=2; plural=(n != 

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:
 Type:  Bug  |  garcia_marc
Component:   |   Status:  closed
  Internationalization   |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ramiro):

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


Comment:

 In [17190]:
 {{{
 #!CommitTicketReference repository="" revision="17190"
 Fixed #11240 -- Made makemessages i18n command escape % symbols in
 literals passed to the trans tag.

 This avoids problems with unintended automatic detection, marking and
 validation of Python string formatting specifiers performed by
 xgettext(1)/msgfmt(1) that stem from the fact that under the hood
 makemessages
 converts templates to Python code before passing them to xgettext.

 This also makes it consistent with its behavior on literals passed to the
 blocktrans tag.

 Thanks Jannis and claude for reviewing and feedback.
 }}}

-- 
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] #17375: 'makemessages' ignores plural from 'blocktrans'

[Django]

#17375: 'makemessages' ignores plural from 'blocktrans'
--+
 Reporter:  ahagenbruch   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by 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] #17266: psycopg2 backend should use get_parameter_status to check if SET TIME ZONE is needed

[Django]

#17266: psycopg2 backend should use get_parameter_status to check if SET TIME 
ZONE
is needed
-+-
 Reporter:  akaariai |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 Attached patch is probably good to go.

 Since we don't have control over PostgreSQL's configuration in the test
 suite, there are no tests. I tested manually and reproduced Anssi's
 results.

-- 
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] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
+
 Reporter:  brutasse|Owner:  brutasse
 Type:  New feature |   Status:  new
Component:  Forms   |  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by tgecho):

 * cc: tgecho (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] #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:
 Type:  Bug  |  garcia_marc
Component:   |   Status:  reopened
  Internationalization   |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

 * cc: claude@… (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] #17365: Extend test discovery to include unittest2 test suite runner

[Django]

#17365: Extend test discovery to include unittest2 test suite runner
---+
 Reporter:  jezdez |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by carljm):

 Replying to [comment:12 russellm]:
 > +1 to everything Jacob said, with one caveat: There is a historical
 reason for looking for tests in models.py -- that's the way you could
 easily find doctests on any of your model methods.  I'm not arguing that
 this is a reason to include models.py, but given that there was method in
 the madness of including models.py in the search path in the first place,
 if we choose to remove models.py, we need to make sure the change is
 documented.

 Certainly I think all changes in behavior, including models.py no longer
 being included in test discovery, need to be well documented in the
 release notes (as well as updating the testing documentation to match the
 new behavior).

 > I'm also interested to know how this would impact on any plans to
 introduce better support for "suites"; I've had a couple of discussions in
 recent times, as well as a long running desire to provide a way to
 separate true unit test (e.g., check that contrib.auth works) from
 integration tests (e.g., checking that contrib.auth is deployed correctly)
 from acceptance tests (e.g., testing that contrib.auth works in practice
 against a browser test suite). I haven't given any specific thought to how
 this would be implemented, but if we're going to make a change to test
 discovery, it would be good to know that the idea has been considered,
 even if we dont' deliver on the actual capability.

 So my best idea of how this could be implemented would be by making use of
 unittest2 skipIf/skipUnless decorators, in combination with an option to
 `manage.py test` to set some arbitrary "flags" that the skip decorators
 could access. So for instance, a decorator that lets you annotate a test
 with `@skipUnlessFlag("integration")`, and `python manage.py test
 --flag=integration`. This is just a rough idea with very little research
 done - I'd want to take a closer look at how e.g. nose and pytest handle
 test annotations, or if unittest2 provides anything already in this
 direction that I'm not aware of. Open questions would also include whether
 it should just be a generic "test annotation/flag" system, or something
 more specifically targeted to split "unit" vs "integration" tests (which
 IMO would only make sense if it also came along with some automatic
 settings-isolation features for the unit tests, or something).

 Anyway, I think that's all pretty much orthogonal to test discovery, which
 is what this patch is about. I'd be opposed to any solution for splitting
 unit and integration tests that relied on putting the different types of
 tests in magical locations; that's the only type of solution I can think
 of that would intersect with the concerns of this ticket.

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

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

Re: [Django] #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:
 Type:  Bug  |  garcia_marc
Component:   |   Status:  reopened
  Internationalization   |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #17341: Model.save() commits transactions after every parent class save

[Django]

#17341: Model.save() commits transactions after every parent class save
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Ok, here is a patch. In my opinion it does make it easier to understand
 what is going on in the saving process. I have tried to make sure saving
 works just like before. The only behavioral change should be committing
 only once, after all tables have been saved. At least the tests agree I
 haven't broken anything.

 There is one thing I don't like, and that is the parameter name
 "topmost_concrete". It is needed so that we know to send signals only
 once, after the last concrete (non-proxy) model's table is saved. Better
 names (or better logic) welcome. Before this was done using origin, which
 was self.`__class__`, until first concrete model was seen, and after that
 it was None. The information in origin was not needed for anything else
 than checking when to send signals.

-- 
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] #17266: psycopg2 backend should use get_parameter_status to check if SET TIME ZONE is needed

[Django]

#17266: psycopg2 backend should use get_parameter_status to check if SET TIME 
ZONE
is needed
-+-
 Reporter:  akaariai |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Thanks, I was just missing this piece of information:
 > late versions (at least 2.4.2) of psycopg are smart enough to skip the
 SET queries for client_encoding and transaction_isolation if they are
 already correct

 I'm going to rework the patch slightly and commit it.

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

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

Re: [Django] #17266: psycopg2 backend should use get_parameter_status to check if SET TIME ZONE is needed

[Django]

#17266: psycopg2 backend should use get_parameter_status to check if SET TIME 
ZONE
is needed
-+-
 Reporter:  akaariai |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 The documentation talks about postgresql.conf. That is, setting those
 parameters is done in postgresql.conf, or for the user you use for taking
 the connection. That is, those are hints for things you should do to your
 PostgreSQL setup. If you do change those, you will get fewer queries
 (including a removed extra commit for timezone) in connection setup. The
 parameters are set up for each new connection, but late versions (at least
 2.4.2) of psycopg are smart enough to skip the SET queries for
 client_encoding and transaction_isolation if they are already correct. And
 the included get_parameter_status change allows for skipping the SET
 timezone.

 I don't know if it is a good idea to include this hint in the
 documentation, but I figured that it is better to mention it than keep it
 as hidden knowledge. Also, the documentation probably needs to be more
 clear. If you missed this, then so will others. Me need better writing
 skills :)

-- 
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] #17375: 'makemessages' ignores plural from 'blocktrans'

[Django]

#17375: 'makemessages' ignores plural from 'blocktrans'
-+-
 Reporter:  ahagenbruch  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  SVN
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Seems to trigger this bug: https://savannah.gnu.org/bugs/index.php?35027

 One possible workaround in makemessages could be to pass a list of files
 to xgettext instead of concatenating messages for each individual file, as
 xgettext seems to properly handle the merge.

-- 
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] #17375: 'makemessages' ignores plural from 'blocktrans'

[Django]

#17375: 'makemessages' ignores plural from 'blocktrans'
--+
 Reporter:  ahagenbruch   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I have two files with equal strings to translate, in the first file
 with `trans` and in the second file with `blocktrans` and a plural form:

 {{{
 a.html:
 {% trans 'My string' %}
 }}}

 {{{
 b.html:
 {% blocktrans count counter=mylist|length %}My string{% plural %}My
 strings{% endblocktrans %}
 }}}

 and when I run `django-admin.py makemessages -l de` I get

 {{{
 django.po
 #: templates/a.html:108
 #: templates/b.html:3
 msgid "My string"
 msgstr ""
 }}}

 and not as you'd expect

 {{{
 django.po
 #: templates/a.html:108
 #: templates/b.html:3
 msgid "My string"
 msgid_plural "My strings"
 msgstr[0] ""
 msgstr[1] ""
 }}}

 I can reproduce this for similar structures in other files.
 `blocktrans` strings that don't have `trans` equivalents in other
 files correctly produce entries with plural forms in the .po file.

-- 
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] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
 Reporter:  Manfred Wassmann |Owner:  jgelens
   |   Status:  assigned
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  dceu2011 |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)


Comment:

 Sorry, I still found one more problem, and some smaller issues:
   - The distinct() in postgresql_psycopg2/operations.py doesn't take
 aliases into account. It assumes that the distinct is always for the main
 table alias. If you first do a filter on m2m relation, then a distinct on
 for the m2m relation you get:
 {{{
 # I added coworkers = models.ManyToManyField('self') to Staff model used
 in tests
 >>> print
 Staff.objects.distinct('coworkers__name').order_by('coworkers__name').query
 SELECT DISTINCT ON ("queries_staff"."name")
  "queries_staff"."id", "queries_staff"."name",
 "queries_staff"."organisation", T3."name"
 FROM "queries_staff"
 LEFT OUTER JOIN "queries_staff_coworkers"
  ON ("queries_staff"."id" = "queries_staff_coworkers"."from_staff_id")
 LEFT OUTER JOIN "queries_staff" T3
  ON ("queries_staff_coworkers"."to_staff_id" = T3."id")
 ORDER BY T3."name" ASC
 }}}
 If you execute that query, it will error, because distinct on is for
 "queries_staff"."name", but order by is for T3."name"

   - In the attached patch there is a different approach of join cleanup.
 It also fixes one other long-standing expected_failure test in queries.
 The failure is related to similar "lingering joins" done by ordering.
   - The `obj.query.distinct_fields = []` in query.distinct() is not
 needed. The variable will be set anyways in
 sql.query.add_distinct_fields(). obj.query.distinct = True can also be set
 in add_distinct_fields()
   - Should the joins be generated as OUTER or INNER joins? Not sure about
 this. I guess either way will be fine. The attached patch generates OUTER
 JOINS (because it uses similar code than the order by join creation).
   - Prevent different distinct_fields lists when combining querysets.

 I attached a patch which fixes these issues. It isn't the cleanest one
 (non-DRY, code copy from order_by). But it can be used as a basis for a
 cleaner patch if needed.

 I did also check out how to support aggregates with distinct_fields.
 However I had a hard time figuring out a realistic test case, so I removed
 that part. So, jgelens is absolutely correct here: better to first find an
 use case :)

 All in all, the only major issue is the correct alias usage in
 compiler.py. The rest is just nitpicking. In my opinion the alias usage
 needs to be fixed before commit, but I may be over-complicating things
 again... Other than that I think this feature is now very solid. I might
 be fine to just let the distinct() generated joins linger in there after
 all. That is what order_by has done for ages.

 The attached patch passes all tests, with one long-standing expected
 failure now gone. As said the patch is just to show one possible approach
 to the alias issue. I hope jgelens will check it out and see what to do to
 the above mentioned issues (if anything).

-- 
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] #17319: Internationalization documentation

[Django]

#17319: Internationalization documentation
--+
 Reporter:  dolma33@… |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  internationalization  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by bpeschier):

 aaugustin's version is better, just improved one sentence.

-- 
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] #16563: Error pickling request.user

[Django]

#16563: Error pickling request.user
-+
 Reporter:  zero.fuxor@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by lukeplant):

 @kmike: That doesn't quite work, but it is close. My attached patch works
 in some cases, if someone can verify that it fixes the issue with a real
 User instance in environment showing the bug, I will commit it.

 I added the code to `SimpleLazyObject` not `LazyObject`, to minimize
 impact with other subclasses of `LazyObject`. `SimpleLazyObject` is not
 designed to be subclassed really - you are supposed to use it just by
 passing a callable to the constructor.

 There is one potential backwards compatibility concern here: if you had
 used a `SimpleLazyObject` with a callable that was itself pickleable, it
 would previously have been possible to pickle that `SimpleLazyObject`
 without the patch. Potentially, the object could have been pickled in the
 'lazy' state, without the callable having been called.

 However, I've tested this, and it seems that - for whatever reason -
 calling `pickle.dumps` causes the the callable to be called. Therefore,
 the object is not serialised in a 'lazy' state - it is always 'evaluated'.
 And this is just the same as it currently is, except we have made it
 explicit. The only difference now is that `SimpleLazyObject._setupfunc` is
 ''never'' available now after unpickling, but that shouldn't be a problem
 since it is never used.

 I'm therefore fairly confident that this patch shouldn't cause other
 problems.

-- 
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] #17093: Refactor django.template to quarantine global state

[Django]

#17093: Refactor django.template to quarantine global state
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by kmike):

 * cc: kmike84@… (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] #16563: Error pickling request.user

[Django]

#16563: Error pickling request.user
-+
 Reporter:  zero.fuxor@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.3
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by kmike):

 * cc: kmike84@… (added)


Comment:

 Are there obstacles for making LazyObject instances picklable? E.g.:

 {{{
 class LazyObject(object):
 # ...

 def __getstate__(self):
 if self._wrapped is None:
 self._setup()
 return self._wrapped

 def __setstate__(self, state):
 self._wrapped = state
 }}}

-- 
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] #17194: Auth tests failing on non-US locales

[Django]

#17194: Auth tests failing on non-US locales
+
 Reporter:  hcarvalhoalves  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.auth|  Version:  SVN
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+

Comment (by bpeschier):

 If you go that approach, it might be a good idea to actually place the
 error messages on the relevant forms and fields so you can reuse them in
 the tests.

 It's also better to reuse the html-escape from django (in
 django.utils.html) instead of creating a new one.

 Attached a patch.

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

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

Re: [Django] #17365: Extend test discovery to include unittest2 test suite runner (was: Extend test discovery to inlcude unittest2 test suite runner)

[Django]

#17365: Extend test discovery to include unittest2 test suite runner
---+
 Reporter:  jezdez |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

-- 
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] #16397: BaseCommand.execute() swallows ImportError, CommandError even when --traceback is used

[Django]

#16397: BaseCommand.execute() swallows ImportError, CommandError even when
--traceback is used
-+-
 Reporter:  charles@…|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.3
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


Comment:

 #11667 was closed as a duplicate, check the discussions and patches over
 there before committing a fix for this ticket.

 #17369 was also closed as a duplicate.

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

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

Re: [Django] #11667: Full traceback if import error before model validation

[Django]

#11667: Full traceback if import error before model validation
-+-
 Reporter:  jedie|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  1.1
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 I'm closing this ticket in favor of #16397 which reports the same problem
 (as far as I can tell) and has a more recent patch.

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

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

Re: [Django] #17369: Useless error messages in management command execution

[Django]

#17369: Useless error messages in management command execution
-+-
 Reporter:  valexeev |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by aaugustin):

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


Comment:

 This appears to be a duplicate of #16397 and #11667.

-- 
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] #17367: PREPEND_WWW should warn on POSTs too

[Django]

#17367: PREPEND_WWW should warn on POSTs too
---+--
 Reporter:  Tuttle |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (URLs)|  Version:  SVN
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by aaugustin):

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


Comment:

 As pointed out in #5718, `PREPEND_WWW` isn't generally useful in
 development: it redirects you to `www.localhost:8000` or
 `www.127.0.0.1:8000`.

 You could edit your hosts file to point `www.yoursite.com` to 127.0.0.1,
 but then you can no longer access the "real" website, and I don't think
 many people do that.

 Technically, adding the warning is trivial; could you just clarify the use
 case?

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

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

Re: [Django] #17214: incorrect rendering of inline fk when parent has custom pk field

[Django]

#17214: incorrect rendering of inline fk when parent has custom pk field
-+-
 Reporter:  Aryeh Leib Taurog|Owner:  nobody
  |   Status:  reopened
 Type:  Bug  |  Version:  1.3
Component:  Forms|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Since your report contains enough detail to reproduce the problem, and the
 bug looks plausible, I'm accepting the ticket (I didn't attempt to
 reproduce it myself).

-- 
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] #17371: For DELETE requests TestClient encodes data as QUERY_STRING and forces an empty payload

[Django]

#17371: For DELETE requests TestClient encodes data as QUERY_STRING and forces 
an
empty payload
--+
 Reporter:  grzesiof@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * needs_better_patch:   => 1
 * component:  Uncategorized => Testing framework
 * needs_tests:   => 0
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Indeed, I don't think Django should do anything special for requests other
 than GET/HEAD and POST.

 For GET and POST requests, Django provides decoded arguments in the
 `request.GET` and `request.POST` dictionaries, because that's what
 browsers use. It makes sense for the test client to provide the reverse
 encoding. And HEAD is well defined as being the same thing as GET.

 For all other HTTP methods, including DELETE, Django won't process the
 request body, see #12635. So it would be more consistent if the test
 client didn't perform encoding — it currently does for PUT (like POST) and
 DELETE (like GET). See attached patch.

 This patch probably breaks a bunch of tests, and I haven't decided what to
 do wrt. backwards compatibility yet. But I'm supporting the idea of making
 the test client more predictable.

 See also #17360.

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