Re: [Django] #15828: multiple inheritance in TestCases does not work with unittest2

[Django]

#15828: multiple inheritance in TestCases does not work with unittest2
---+
 Reporter:  ricardokirkner |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords:  unittest2  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by voidspace):

 I don't know why users of Python 2.7.2 will see a bug? The problem only
 exists for unittest2 which overrode the base unittest.TestCase.setUp
 surely? (So for users of Python 2.7 using unittest.TestCase directly
 instead of unittest2.TestCase the problem doesn't exist - unless I'm
 misunderstanding something.)

 Note that just bundling the Python 2.7 version of unittest is not a good
 alternative to bundling unittest2. unittest2 includes fixes for
 compatibility with earlier versions of Python - plus it explicitly
 inherits from the appropriate unittest classes. If you just bundled the
 2.7 stdlib unittest then your TestCase would not be a subclass of the
 "real" unittest.TestCase, which would likely cause problems for many test
 runners.

-- 
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] r17400 - django/trunk/django/template

[noreply]

Author: adrian
Date: 2012-01-27 17:50:14 -0800 (Fri, 27 Jan 2012)
New Revision: 17400

Modified:
   django/trunk/django/template/base.py
Log:
Made a tiny performance improvement in the template system's Parser.parse() -- 
don't look up the global variables TOKEN_TEXT, etc.

Modified: django/trunk/django/template/base.py
===
--- django/trunk/django/template/base.py2012-01-27 23:46:22 UTC (rev 
17399)
+++ django/trunk/django/template/base.py2012-01-28 01:50:14 UTC (rev 
17400)
@@ -237,15 +237,16 @@
 nodelist = self.create_nodelist()
 while self.tokens:
 token = self.next_token()
-if token.token_type == TOKEN_TEXT:
+# Use the raw values here for TOKEN_* for a tiny performance boost.
+if token.token_type == 0: # TOKEN_TEXT
 self.extend_nodelist(nodelist, TextNode(token.contents), token)
-elif token.token_type == TOKEN_VAR:
+elif token.token_type == 1: # TOKEN_VAR
 if not token.contents:
 self.empty_variable(token)
 filter_expression = self.compile_filter(token.contents)
 var_node = self.create_variable_node(filter_expression)
 self.extend_nodelist(nodelist, var_node, token)
-elif token.token_type == TOKEN_BLOCK:
+elif token.token_type == 2: # TOKEN_BLOCK
 try:
 command = token.contents.split()[0]
 except IndexError:

-- 
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] #17604: Make use of assertTemplateUsed and assertTemplateNotUsed as ContextManagers

[Django]

#17604: Make use of assertTemplateUsed and assertTemplateNotUsed as 
ContextManagers
-+-
 Reporter:  gregmuellegger   |Owner:
 Type:  New feature  |  gregmuellegger
Component:  Testing framework|   Status:  new
 Severity:  Normal   |  Version:  1.3
 Keywords:  assertTemplateUsed,  |   Resolution:
  assertTemplateNotUsed, | Triage Stage:
  contextmanager |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gregmuellegger):

 * has_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17604: Make use of assertTemplateUsed and assertTemplateNotUsed as ContextManagers

[Django]

#17604: Make use of assertTemplateUsed and assertTemplateNotUsed as 
ContextManagers
-+-
 Reporter:  gregmuellegger   |Owner:
 Type:  New feature  |  gregmuellegger
Component:  Testing framework|   Status:  new
 Severity:  Normal   |  Version:  1.3
 Keywords:  assertTemplateUsed,  |   Resolution:
  assertTemplateNotUsed, | Triage Stage:
  contextmanager |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gregmuellegger):

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


Comment:

 The feature is implemented here:
 https://github.com/gregmuellegger/django/tree/t17604-assertTemplateUsed
 The compare view:
 
https://github.com/gregmuellegger/django/compare/master...t17604-assertTemplateUsed

 Would be good if anyone could in particular review the docs, since my
 english is not the best at the moment.

-- 
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] #17604: Make use of assertTemplateUsed and assertTemplateNotUsed as ContextManagers

[Django]

#17604: Make use of assertTemplateUsed and assertTemplateNotUsed as 
ContextManagers
-+-
 Reporter:   |  Owner:  gregmuellegger
  gregmuellegger | Status:  new
 Type:  New  |Version:  1.3
  feature|   Keywords:  assertTemplateUsed,
Component:  Testing  |  assertTemplateNotUsed, contextmanager
  framework  |  Has patch:  0
 Severity:  Normal   |  UI/UX:  0
 Triage Stage:   |
  Unreviewed |
Easy pickings:  0|
-+-
 It can be useful to use the assertTemplateUsed assertion on a limited
 block of code via a context manager instead on a request:

 {{{
 with self.assertTemplateUsed('template_used/base.html'):
 render_to_string('template_used/base.html')
 }}}

 This is something that already proofed useful in the soc2011/form-
 rendering branch. It's implemented there and is well tested:
 https://github.com/gregmuellegger/django/blob/soc2011/form-
 rendering/django/test/testcases.py#L720

 Same is true for assertTemplateNotUsed.

-- 
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] #17111: simple redirect_to: handle query strings with percent symbols

[Django]

#17111: simple redirect_to: handle query strings with percent symbols
-+-
 Reporter:  acdha|Owner:  cadams
 Type:  Bug  |   Status:  closed
Component:  Generic views|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  i18n | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by anonymous):

 Thanks for the fix, acdha. I set up redirect_to earlier today, was getting
 errors immediately from users, and am happy to see a quick fix!

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

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

[noreply]

Author: adrian
Date: 2012-01-27 15:46:22 -0800 (Fri, 27 Jan 2012)
New Revision: 17399

Modified:
   django/trunk/django/template/base.py
Log:
Made a small optimization to the template lexer. There's no need to calculate 
the len of VARIABLE_TAG_START, et al, each time we create a token.

Modified: django/trunk/django/template/base.py
===
--- django/trunk/django/template/base.py2012-01-27 22:25:44 UTC (rev 
17398)
+++ django/trunk/django/template/base.py2012-01-27 23:46:22 UTC (rev 
17399)
@@ -204,22 +204,18 @@
 otherwise it should be treated as a literal string.
 """
 if in_tag:
+# The [2:-2] ranges below strip off *_TAG_START and *_TAG_END.
+# We could do len(BLOCK_TAG_START) to be more "correct", but we've
+# hard-coded the 2s here for performance. And it's not like
+# the TAG_START values are going to change anytime, anyway.
 if token_string.startswith(VARIABLE_TAG_START):
-token = Token(TOKEN_VAR,
-  token_string[
-len(VARIABLE_TAG_START):-len(VARIABLE_TAG_END)
-  ].strip())
+token = Token(TOKEN_VAR, token_string[2:-2].strip())
 elif token_string.startswith(BLOCK_TAG_START):
-token = Token(TOKEN_BLOCK,
-  token_string[
-len(BLOCK_TAG_START):-len(BLOCK_TAG_END)
-  ].strip())
+token = Token(TOKEN_BLOCK, token_string[2:-2].strip())
 elif token_string.startswith(COMMENT_TAG_START):
 content = ''
 if token_string.find(TRANSLATOR_COMMENT_MARK):
-content = token_string[
-len(COMMENT_TAG_START):-len(COMMENT_TAG_END)
-  ].strip()
+content = token_string[2:-2].strip()
 token = Token(TOKEN_COMMENT, content)
 else:
 token = Token(TOKEN_TEXT, token_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.

Re: [Django] #17186: Inverted F expression (negation)

[Django]

#17186: Inverted F expression (negation)
-+-
 Reporter:  niwi |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by lrekucki):

 One more thing worth documenting, due to difference in None and NULL
 semantics:

 {{{#!python
 class A(Model):
   f = NullBooleanField()

 for m in A.objects.all():
   m.f = not m.f; m.save()  # all NULL values are now True

 # while this will leave NULL values unchanged as NOT NULL is NULL
 A.objects.update(f=not F('f'))
 }}}

-- 
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] #17186: Inverted F expression (negation)

[Django]

#17186: Inverted F expression (negation)
-+-
 Reporter:  niwi |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by lrekucki):

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


Comment:

 As a new feature this needs documentation. Also:


   * What's the use case for negation on non-boolean values? How does this
 behave on different DBs (the tests should check that).
   * No tests for compounds statements (should they be boolean only?).
   * Why {{{~F()}}} instead of more Pythonic {{{not F()}}}. After all
 {{{~True}}} is {{{-2}}} not {{{False}}}. You could use {{{not}}} for
 boolean expressions and {{{~}}} for bit negation on fields (which might be
 useful too!).

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

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

Re: [Django] #17481: leading zeros are missing from result of pbkdf2

[Django]

#17481: leading zeros are missing from result of pbkdf2
-+---
 Reporter:  bhuztez  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by aaugustin):

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


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

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

Re: [Django] #16735: Queryset values should be aliasable

[Django]

#16735: Queryset values should be aliasable
-+-
 Reporter:  alex.latchford@… |Owner:  nate_b
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  queryset, alias, |  Needs documentation:  0
  values |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by lrekucki):

 * needs_better_patch:  0 => 1


Comment:

 While adding this to {{{values()}}} is perfectly fine, doing the same with
 {{{values_list()}}} feels weird. Also, it's buggy:

 {{{#!python
 # from ValuesListQuerySet in the patch
 fields = list(self._fields) + self._aliased_fields.keys()
 }}}

 This makes the order of values in returned tuples depend on order of
 dictionary keys, which is _undefined_. Just try:

 {{{#!python
 print Model.objects.values_list(a2="field", a3="other_field")
 # on Python 2.7 and 3.2 values should be reversed.
 }}}

-- 
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] #15828: multiple inheritance in TestCases does not work with unittest2

[Django]

#15828: multiple inheritance in TestCases does not work with unittest2
---+
 Reporter:  ricardokirkner |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords:  unittest2  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

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


Comment:

 In [17398]:
 {{{
 #!CommitTicketReference repository="" revision="17398"
 Fixed #15828 -- Removed explicit implementation of empty setUp / tearDown
 methods. Backport of http://hg.python.org/unittest2/rev/3d33f92496fa.
 }}}

-- 
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] r17398 - django/trunk/django/utils/unittest

[noreply]

Author: aaugustin
Date: 2012-01-27 14:25:44 -0800 (Fri, 27 Jan 2012)
New Revision: 17398

Modified:
   django/trunk/django/utils/unittest/case.py
Log:
Fixed #15828 -- Removed explicit implementation of empty setUp / tearDown 
methods. Backport of http://hg.python.org/unittest2/rev/3d33f92496fa.


Modified: django/trunk/django/utils/unittest/case.py
===
--- django/trunk/django/utils/unittest/case.py  2012-01-26 15:00:57 UTC (rev 
17397)
+++ django/trunk/django/utils/unittest/case.py  2012-01-27 22:25:44 UTC (rev 
17398)
@@ -241,9 +241,6 @@
 Cleanup items are called even if setUp fails (unlike tearDown)."""
 self._cleanups.append((function, args, kwargs))
 
-def setUp(self):
-"Hook method for setting up the test fixture before exercising it."
-
 @classmethod
 def setUpClass(cls):
 "Hook method for setting up class fixture before running tests in the 
class."
@@ -252,9 +249,6 @@
 def tearDownClass(cls):
 "Hook method for deconstructing the class fixture after running all 
tests in the class."
 
-def tearDown(self):
-"Hook method for deconstructing the test fixture after testing it."
-
 def countTestCases(self):
 return 1
 

-- 
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] #15828: multiple inheritance in TestCases does not work with unittest2

[Django]

#15828: multiple inheritance in TestCases does not work with unittest2
---+
 Reporter:  ricardokirkner |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:
 Keywords:  unittest2  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 After scratching my head a lot on this problem, I'm just going to remove
 backport http://hg.python.org/unittest2/rev/3d33f92496fa.

 The bug will still be present for users of Python 2.7.2 until it's fixed
 in Python, but there isn't anything we can do about this. They have the
 option to install an hg checkout unittest2 to get a patched version.

 This appears to be the least stupid thing to do.

-- 
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] #17561: EmailField does not automatically lower the case in email addresses

[Django]

#17561: EmailField does not automatically lower the case in email addresses
-+-
 Reporter:  zechs.marquie@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  EmailField,  |  Unreviewed
  duplicates |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Django shouldn't alter user input. IMO this ticket is "wontfix" anyway.

-- 
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] #8874: problem with URLs on FastCGI after update to 1.0

[Django]

#8874: problem with URLs on FastCGI after update to 1.0
---+
 Reporter:  kyprizel   |Owner:  kyprizel
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Other)   |  Version:  SVN
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by aaugustin):

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


Comment:

 See #17550 for an annoying consequence of this fix.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17550: WSGI request to /subdir/subdir returns the index page

[Django]

#17550: WSGI request to /subdir/subdir returns the index page
-+---
 Reporter:  vdboor   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.4-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 As explained in
 
[https://code.djangoproject.com/browser/django/trunk/django/core/handlers/wsgi.py?annotate=blame#L129
 the source], this condition is a workaround for a bug in flup, reported in
 #8490 and fixed at r8569. I don't know if that bug was reported to flup.

 flup 1.0.2 was released 2.5 years ago, if it fixes the bug, maybe we can
 get rid of this hack...

-- 
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] #17561: EmailField does not automatically lower the case in email addresses

[Django]

#17561: EmailField does not automatically lower the case in email addresses
-+-
 Reporter:  zechs.marquie@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:  EmailField,  |  Unreviewed
  duplicates |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by lrekucki):

 I'm not sure adding another option to save you 2 lines in not so common
 case is a good idea.

 One thing to note is that only the *local part* of the email is case
 sensitive. Host names are by definition case insensitive (at least in
 ASCII range, not sure about IDN), ie. {{{me...@example.com}}} and
 {{{me...@example.com}}} are the same address. IMO, doing such
 normalization is useful, but it's a bit different thing then proposed on
 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] #17566: RegexURLResolver.__repr__(self) is not unicode safe.

[Django]

#17566: RegexURLResolver.__repr__(self) is not unicode safe.
---+---
 Reporter:  otto   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Core (URLs)|  Version:  1.4-alpha-1
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by aaugustin):

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


Comment:

 How did you encounter this error?

 `urlconf_name` is the import path of the URLconf module, and Python
 doesn't support unicode module names (at least until Python 3.2), so it
 should always be an ASCII string.

-- 
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] #17565: Cache back-references on OneToOne fields

[Django]

#17565: Cache back-references on OneToOne fields
-+-
 Reporter:  shai |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  OneToOneField,   |  Needs documentation:  0
  OneToOne   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Discussed on the mailing list here: http://groups.google.com/group/django-
 developers/browse_thread/thread/b8dd06eb13ccc8c2

 See comments by Adrian and Carl in particular.

-- 
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] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by pmartin):

 Obviously it is a nosense use Q when you only have one lookup. It's
 possible that the example would be more clarifier if you change the last
 query for this:


 {{{
 User.objects.exclude(Q(groups__in=[g1.pk])|Q(username='u2'))
 }}}

 This should return :

 {{{
 []
 }}}

 But return:

 {{{
 []
 }}}

-- 
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] #17576: Enclosing quotation marks for urlize. (Or make urlize easier to override)

[Django]

#17576: Enclosing quotation marks for urlize.  (Or make urlize easier to 
override)
-+---
 Reporter:  tomchristie  |Owner:  tomchristie
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by aaugustin):

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


Comment:

 +0 for option 1.

 -1 for option 2, as it would be quite ugly to pass arguments to urlize in
 a template.

 NB: technically, it's already possible to import WRAPPING_PUNCTUATION and
 TRAILING_PUNCTUATiON and mutate them — but of course they aren't a public
 API and may change any time, see r17362 for instance.

-- 
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] #13914: Add natural keys to contrib.auth.User and Group models

[Django]

#13914: Add natural keys to contrib.auth.User and Group models
-+-
 Reporter:  jbochi   |Owner:  aaugustin
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  Contrib, Auth,   | Triage Stage:  Ready for
  User, Group, natural keys  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 Looks nice for me, 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] #17603: Forms have list-mutability issues with field validator lists

[Django]

#17603: Forms have list-mutability issues with field validator lists
-+--
 Reporter:  brett@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.3
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by claudep):

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


Comment:

 This has been fixed in #17127 (will be in 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] #17583: Add raw kwarg to m2m signals

[Django]

#17583: Add raw kwarg to m2m signals
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  signal, m2m  |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * stage:  Unreviewed => Design decision needed


Comment:

 That does work, but it's a pretty unpleasant solution. I'd like to know
 the design decision behind that option existing on models but not M2M -
 consistent design seems more suitable to me than stack inspection hacks.

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

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

Re: [Django] #17601: Error code from database exception should not be lost during exception handling (psycopg2)

[Django]

#17601: Error code from database exception should not be lost during exception
handling (psycopg2)
-+-
 Reporter:  zimnyx   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 Sure, all value-added information we can bring might be useful for the
 poor debugging dev :-)

-- 
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] #17603: Forms have list-mutability issues with field validator lists

[Django]

#17603: Forms have list-mutability issues with field validator lists
+
 Reporter:  brett@… |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.3
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 {{{
 from django.forms import Form
 from django.forms.fields import IntegerField
 from django.core.validators import MinValueValidator

 class SampleForm(Form):
 some_field = IntegerField()

 def __init__(self, *args, **kwargs):
 super(SampleForm, self).__init__(*args, **kwargs)
 self.fields['some_field'].validators.append(MinValueValidator(1))

 first_form = SampleForm()
 print len(first_form.fields['some_field'].validators)
 # Prints 1

 second_form = SampleForm()
 print len(second_form.fields['some_field'].validators)
 # Prints 2
 }}}

 I believe this has to do with the fact that the __deepcopy__ method on
 Field , which does a shallow copy of everything except for 'widget'. I
 could see two potential solutions here:
  * Do a deepcopy on everything (potentially risky)
  * Do a deepcopy on validators and any other fields which could
 potentially be a list.

 While searching, I found ticket #4167, which was similar to this, but
 pertained more to the Field class itself having mutability issues rather
 than the Form initialization code.

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

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

Re: [Django] #9112: New releases do not reliably overwrite old ones

[Django]

#9112: New releases do not reliably overwrite old ones
-+-
 Reporter:  holdenweb|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  release engineering  | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 Unfortunately, we can only fix it in the release process, which (to the
 best of my knowledge) isn't documented, except in the release manager's
 brains...

-- 
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] #2713: Sitemap Index with Cache gives a NoReverseMatch exception

[Django]

#2713: Sitemap Index with Cache gives a NoReverseMatch exception
--+-
 Reporter:  JayKlehr  |Owner:  aaugustin
 Type:  Bug   |   Status:  new
Component:  contrib.sitemaps  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by aaugustin):

 * owner:  stavros => aaugustin


-- 
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] #17602: Django serializer does unnecessary db queries

[Django]

#17602: Django serializer does unnecessary db queries
---+
 Reporter:  anuraguniyal   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When django serializes object, to get the foreign key id referenced in
 object it queries the db instead of just using the id e.g.

 {{{#!python
 class QBAccount(CompanyModel):
 company = models.ForeignKey(Company)

 >>> from deretoapp.models import QBAccount
 >>> import logging
 >>> l = logging.getLogger('django.db.backends')
 >>> l.setLevel(logging.DEBUG)
 >>> l.addHandler(logging.StreamHandler())
 >>> a = QBAccount.allobjects.all()[0]
 >>> from django.core import serializers
 >>> serializers.serialize('python', [a])
 (0.000) SELECT `deretoapp_company`.`id`, ... FROM `deretoapp_company`
 WHERE `deretoapp_company`.`id` = 45995613-adeb-488f-9556-d69e856abe5f ;
 args=(u'45995613-adeb-488f-9556-d69e856abe5f',)
 [{'pk': u'3de881eb-8409-4089-8de8-6e24f7281f37', 'model':
 u'deretoapp.qbaccount', 'fields': {... 'company': u'45995613-adeb-
 488f-9556-d69e856abe5f' }}]
 }}}

 Here db query after `serializers.serialize` is not needed because compay
 id could have been obtained directly by `a.company_id`, and query itself
 shows id is being passed to db to get the id, it looks like problem is
 because `a.company.id` is a db query which in ideal world also should not
 happen.

-- 
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] #10868: _destroy_test_db exposes the production database to possibly destructive actions from the unit tests

[Django]

#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-+-
 Reporter:  ovidiu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:  django.test  | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by akaariai):

 Maybe it would be better to write these lines:
 {{{
 self.connection = backend.DatabaseWrapper(
 settings_dict,
 alias='__destroy_test_db__',
 allow_thread_sharing=False)
 self._destroy_test_db(test_database_name, verbosity)
 }}}

 As just
 {{{
 newconn = backend.DatabaseWrapper(...)
 newconn.ops._destroy_test_db(test_database_name, verbosity)
 }}}

 The coding in the patch breaks the symmetrical linking between DBWrapper
 and Ops. If you go from DBWrapper to Ops and then back to the connection
 again, you don't actually end up into the same DBWrapper (or:
 ops.connection.ops != ops). While that isn't critical at all, it might
 cause a surprise some day.

 But in any case the basic approach seems now correct. It is simple and
 should prevent accidental access to production DB. It is easy to override
 the default behavior by a custom `TestRunner`. So, I am +1 to commit of
 this. It would be nice to test this somehow, even if the test can not be
 included in the test suite. I try to see if I have time to write a small
 custom testproject testing threads sharing etc this weekend.

-- 
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] #9112: New releases do not reliably overwrite old ones

[Django]

#9112: New releases do not reliably overwrite old ones
-+-
 Reporter:  holdenweb|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  release engineering  | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by lukeplant):

 * severity:  Normal => Release blocker


Comment:

 I'm marking this a release blocker, since it is quite possibly security
 related: you could think you have installed a fix, but haven't at all.

-- 
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] #9549: Give initial_data.* files an option for not over writing current data.

[Django]

#9549: Give initial_data.* files  an option for not over writing current data.
-+-
 Reporter:  MrNarwhal|Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Core |  Version:  1.0
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  initial data,|  Needs documentation:  1
  syncdb, json, xml, yaml|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 #15926 is related.

-- 
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] #15926: Option to not load initial fixtures during syncdb

[Django]

#15926: Option to not load initial fixtures during syncdb
-+-
 Reporter:  msiedlarek   |Owner:
 Type:  New feature  |  msiedlarek
Component:  Core (Management |   Status:  new
  commands)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  management syncdb| Triage Stage:  Accepted
  options fixtures   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by aaugustin):

 #9549 is related.

-- 
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] #9549: Give initial_data.* files an option for not over writing current data.

[Django]

#9549: Give initial_data.* files  an option for not over writing current data.
-+-
 Reporter:  MrNarwhal|Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Core |  Version:  1.0
  (Serialization)|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  initial data,|  Needs documentation:  1
  syncdb, json, xml, yaml|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by etox):

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


Comment:

 I'm very interested in this feature, so I'd be happy to finish whatever
 the ticket needs to be committed. Is documentation what has blocked this
 ticket for 3 years now?

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

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

Re: [Django] #17474: Problem when the request doesn't have Content-Type.

[Django]

#17474: Problem when the request doesn't have Content-Type.
-+-
 Reporter:  Marcelo Salhab   |Owner:  nobody
  Brogliato  |   Status:  reopened
 Type:  Bug  |  Version:  1.3
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  content-type |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by olau):

 * cc: olau@… (added)
 * status:  closed => reopened
 * resolution:  needsinfo =>


Comment:

 Hi!

 We had the same problem with a Django instance running inside mod_python
 (yes, I know mod_python is bad, it's a client's server). I think it
 happens with a custom iPhone client. Here's the traceback:

 {{{
 Traceback:
 File "/var/sites/bcl/PYTHON_ENV/lib/python2.5/site-
 packages/django/core/handlers/base.py" in get_response
   111. response = callback(request,
 *callback_args, **callback_kwargs)
 File "/var/sites/bcl/main/api.py" in inner
   17. token = request.GET.get("authtoken",
 request.POST.get("authtoken"))
 File "/var/sites/bcl/PYTHON_ENV/lib/python2.5/site-
 packages/django/core/handlers/modpython.py" in _get_post
   101. self._load_post_and_files()
 File "/var/sites/bcl/PYTHON_ENV/lib/python2.5/site-
 packages/django/http/__init__.py" in _load_post_and_files
   270. if self.META.get('CONTENT_TYPE',
 '').startswith('multipart'):

 Exception Type: AttributeError at /api/events/log/
 Exception Value: 'NoneType' object has no attribute 'startswith'
 }}}

 If you want to test it, you could try telnetting a POST response,
 something like "telnet localhost 8000", then copy-paste
 {{{
 POST / HTTP/1.0
 Content-length: 17

 query=1234
 }}}

-- 
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] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by pmartin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * stage:  Unreviewed => Design decision needed


-- 
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] #17601: Error code from database exception should not be lost during exception handling (psycopg2)

[Django]

#17601: Error code from database exception should not be lost during exception
handling (psycopg2)
--+
 Reporter:  zimnyx|  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Here is a fragment from
 
source:django/trunk/django/db/backends/postgresql_psycopg2/base.py?rev=17244#L50
 {{{
 def execute(self, query, args=None):
 try:
 return self.cursor.execute(query, args)
 except Database.IntegrityError, e:
 raise utils.IntegrityError, utils.IntegrityError(*tuple(e)),
 sys.exc_info()[2]
 except Database.DatabaseError, e:
 raise utils.DatabaseError, utils.DatabaseError(*tuple(e)),
 sys.exc_info()[2]
 }}}

 In case of Psycopg2 and database exceptions, error code is set as psycopg2
 exception propery called
 [http://initd.org/psycopg/docs/module.html#psycopg2.Error.pgcode "pgcode"]
 instead of being passed as exception argument, so this way we're loosing
 info about "pgcode" which is valuable. Handling database exception by
 parsing error message is a bit awkward.

 I'm not sure if other backends are affected by this issue, but I can
 investigate and provide a patch if we agree on this issue.


 P.S.[[BR]]
 I've just filled a bug in this subject against Psycopg2:
 http://psycopg.lighthouseapp.com/projects/62710-psycopg/tickets/96-pgcode-
 should-be-present-in-exceptionargs
 If they fix it, this ticket will become "worksforme".

-- 
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] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
--+
 Reporter:  pmartin   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 If I have the next code:

 {{{
class A(models.Model):

.

 class B(models.Model):

 a = models.ManyToManyField(A)

 }}}
 The next queries get differents results:


 {{{
 B.objects.exclude(a__in=[7])

 from django.db.models import Q
 B.objects.exclude(Q(a__in=[7]))
 }}}

 Results:

 The first query get all objects excluding the "b objects" with a=7. It's
 Ok
 But the second query get all objects excluding the "b objects" with a=7 or
 a=None.
 Is it an error?, Is it known?

 I add a verbose example, execute the next code

 {{{
 from django.contrib.auth.models import User, Group
 u1 = User.objects.create(username='u1')
 u2 = User.objects.create(username='u2')
 u3 = User.objects.create(username='u3')
 g1 = Group.objects.create(name='g1')
 g2 = Group.objects.create(name='g2')
 u1.groups.add(g1)
 u2.groups.add(g2)
 print User.objects.exclude(groups__in=[g1.pk])
 print User.objects.exclude(Q(groups__in=[g1.pk]))
 }}}

 I have seen the [https://docs.djangoproject.com/en/dev/topics/db/queries/
 documentation] and the
 
[https://code.djangoproject.com/browser/django/trunk/tests/modeltests/or_lookups/tests.py
 tests] and I didn't see any note or reference

-- 
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] #2131: HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: HttpResponseSendFile for serving static files handler-specific sendfile
mechanism
-+-
 Reporter:   |Owner:  ccahoon
  ymasuda[at]ethercube.com   |   Status:  reopened
 Type:  New feature  |  Version:  SVN
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jezdez):

 * status:  closed => reopened
 * needs_docs:  0 => 1
 * component:  Core (Other) => HTTP handling
 * resolution:  wontfix =>


Comment:

 A core developer clearly has marked this ticket as accepted above and non
 of the core devs have argued against it on the mailing list. So in other
 words, this just needs someone to spear head the porting of the changes
 made to the soc2009/http-wsgi-improvements branch.

-- 
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] #2713: Sitemap Index with Cache gives a NoReverseMatch exception

[Django]

#2713: Sitemap Index with Cache gives a NoReverseMatch exception
--+
 Reporter:  JayKlehr  |Owner:  stavros
 Type:  Bug   |   Status:  new
Component:  contrib.sitemaps  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by mvantellingen):

 * needs_tests:  1 => 0


Comment:

 I've updated the patch to work with trunk and added one unittest

-- 
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] #2131: HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: HttpResponseSendFile for serving static files handler-specific sendfile
mechanism
-+-
 Reporter:   |Owner:  ccahoon
  ymasuda[at]ethercube.com   |   Status:  closed
 Type:  New feature  |  Version:  SVN
Component:  Core (Other) |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by guettli):

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


Comment:

 I asked on django-dev about this ticket, there was only one reply. But the
 core developers don't care.

 http://groups.google.com/group/django-
 developers/browse_thread/thread/b02c19daf0af5602/1bea6744f9e2052a?pli=1

 I close this ticket. You have got to use the external django-sendfile
 project.

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

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