Re: [Django] #20226: Django problematic when Oracle when column/table names are mixed case

[Django]

#20226: Django problematic when Oracle when column/table names are mixed case
-+-
 Reporter:  calcium  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  Oracle, ORM  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by calcium):

 For the mixed case table name problem, I get this error when doing a
 $python manage.py inspectdb.

 DatabaseError: ORA-00942: table or view does not exist


 I have traced it down to this line in
 /usr/local/lib/python2.7/dist-
 packages/django/core/management/commands/inspectdb.py

 Line 74 for i, row in
 enumerate(connection.introspection.get_table_description(cursor,
 table_name)):

 And this is where I get stuck. I cannot proceed any further, for now.

 Hope this helps somewhat.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20227: Accept an empty SECRET_KEY when DEBUG is True

[Django]

#20227: Accept an empty SECRET_KEY when DEBUG is True
---+
 Reporter:  lsaffre|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Django should accept an empty SECRET_KEY when DEBUG is True. Okay Django
 1.5 is more severe about security leaks and it's okay to say that a
 SECRET_KEY setting is required
 (https://docs.djangoproject.com/en/dev/releases/1.4/#secret-key-setting-
 is-required), but when DEBUG is True Django shouldn't be so nit-picky.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20226: Django problematic when Oracle when column/table names are mixed case

[Django]

#20226: Django problematic when Oracle when column/table names are mixed case
-+-
 Reporter:  calcium  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  Oracle, ORM  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by calcium):

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


Comment:

 Oops... the line above should read

 + m = map(str.isupper, str(field.column))

 and not

 + m = map(str.isupper, field.column)

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20226: Django problematic when Oracle when column/table names are mixed case

[Django]

#20226: Django problematic when Oracle when column/table names are mixed case
--+-
 Reporter:  calcium   |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.5
 Severity:  Normal|   Keywords:  Oracle, ORM
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+-
 In my Oracle DB, some of the tables have column names which are not
 uppercase only.
 eg
 column names are "FIRSTNAME", and "CallType".

 When running a query against any table with such non-uppercase only
 columnnames, I get an error like

 django.db.utils.DatabaseError: ORA-00904: "SOMETABLENAME"."CALLTYPE":
 invalid identifier.

 I got around my problem by editing the compiler.py file.
 /usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py


 The diff is as follows.

 *** ~/Exploded/Django-1.5.1/django/db/models/sql/compiler.py2013-03-29
 07:07:20.0 +1100
 --- /usr/local/lib/python2.7/dist-
 packages/django/db/models/sql/compiler.py 2013-04-09
 12:56:07.293736020 +1000
 *** class SQLCompiler(object):
 *** 296,302 
 --- 296,305 
   col_aliases.add(c_alias)
   aliases.add(c_alias)
   else:
 + m = map(str.isupper, field.column)
   r = '%s.%s' % (qn(alias), qn2(field.column))
 + if True in m:  # if there is an uppercase, leave it.
 + r = '%s."%s"' % (qn(alias), field.column)
   result.append(r)
   aliases.add(r)
   if with_aliases:



 ie. I check if there is an uppercase in the column name, and if so,
 I quote the column name, leaving the case as it is ie. mixed.
 ie. the column names seem to come in as all lower case and then it
 gets converted to uppercase.
 I'm not sure what to do if the column names are really all lower case.

 This was just a quick and dirty fix for my use.
 I think maybe a more solid fix might be required but just raising it here
 in case anybody just wanted a quick fix.

 A similar problem arises for mixed case table names.
 I didnt do a fix for that, yet.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20225: query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10

[Django]

#20225: query model using `filter` or `get` occur ValueError: invalid literal 
for
int() with base 10
-+-
 Reporter:  592280502@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  *.djangoproject.com  |  Version:  1.3
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  ValueError   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 Sorry, but without instructions to reliably reproduce the failure there's
 not much we can do with this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20225: query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10

[Django]

#20225: query model using `filter` or `get` occur ValueError: invalid literal 
for
int() with base 10
-+
 Reporter:  592280502@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  *.djangoproject.com  |Version:  1.3
 Severity:  Normal   |   Keywords:  ValueError
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 class User(models.Model):
 identifier=models.CharField(max_length=128, unique=True, db_index=True)
 ..
 ..
 class Token(models.Model):
 user = models.ForeignKey("User", related_name="Tokens")
 token_string = models.CharField(max_length=128, unique=True,
 db_index=True)
 while I already have a tk(),I run this:
 user = User.objects.filter(id=tk.user_id) if user: user = user[0]
 it cause the ValueError: invalid literal for int() with base 10:
 File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 113, in nonzero
 iter(self).next()
 File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 107, in _result_iter
 self._fill_cache()
 File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 772, in _fill_cache
 self._result_cache.append(self._iter.next())
 File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 273, in iterator
 for row in compiler.results_iter():
 File "/usr/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 680, in results_iter
 for rows in self.execute_sql(MULTI):
 File "/usr/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 735, in execute_sql
 cursor.execute(sql, params)
 File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 86, in execute
 return self.cursor.execute(query, args)
 File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in
 execute
 self.errorhandler(self, exc, value)
 File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in
 defaulterrorhandler
 raise errorclass, errorvalue
 ValueError: invalid literal for int() with base 10: '\xd9'
 but it disappeared when I restart my project, but a couple of days while
 running, it occured again
 How does it happened and any solutions?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20147: Replace and deprecate request.META for HTTP headers

[Django]

#20147: Replace and deprecate request.META for HTTP headers
---+--
 Reporter:  lukeplant  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by carljm):

 Minor bikeshed-type question: is there really value in making
 `request.HEADERS` all-caps? I realize the parallel to `request.POST`,
 `request.GET`, and `request.META`, but the former two are all-caps simply
 because HTTP methods are usually written that way. I guess I'd just like
 to see a bit of rationale spelled out for how we decide whether a given
 request attribute ought to be all-caps; I'd probably lean towards just
 `request.headers` for the new API.

 More discussion of this proposal (in particular, whether to
 deprecate/change `request.META`) is here:
 https://groups.google.com/d/topic/django-developers/Jvs3F79cY4Y/discussion

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19733: Deprecate ModelForm without explicit fields

[Django]

#19733: Deprecate ModelForm without explicit fields
-+-
 Reporter:  aaugustin|Owner:  lukeplant
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
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|
-+-

Comment (by lukeplant):

 Another issue I'm hitting is to do with `ModelAdmin` validation.

 If you are defining a custom `ModelForm` to be used with `ModelAdmin`,
 then you don't want to add `fields = "__all__"` just to allow it to be
 created, since the `ModelAdmin` should specify that as a default (and
 does). But if you define `Meta.model`, but not `Meta.fields`, you will get
 an error with the proposed changes.

 There is a way around this problem for the common case - simply don't
 define the `Meta` class at all, or don't define `Meta.model` - you don't
 need it, because `ModelAdmin` can create it for you or set the `model`
 attribute if it is missing. However, if you do this, you hit the problem
 described here:

 https://code.djangoproject.com/ticket/19445#comment:7

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19445: Fieldsets' validation doesn't call get_form

[Django]

#19445: Fieldsets' validation doesn't call get_form
---+
 Reporter:  KJ |Owner:  slurms
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by lukeplant):

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


Comment:

 This fix is, unfortunately, inadequate.

 Even if it isn't overridden, `get_form` will return a `ModelForm` class
 that can be significantly different from the `ModelAdmin.form` attribute.

 For example, the following code will work fine if you disable validation,
 but validation will fail:

 {{{
 #!python
 class MyModel(models.Model):
 field1 = models.BooleanField()

 class MyForm(forms.ModelForm):
 my_additional_field = forms.BooleanField()

 class MyAdmin(admin.ModelAdmin):
 form = MyForm
 fieldsets = (
 ('Group', {
   'fields': ['field1', 'my_additional_field']
   }),
 )
 }}}

 This is because `get_form` creates a class based on `MyForm`, but not the
 same - it adds an inner Meta class, so it has a `base_fields` attribute
 that will work, while the statically defined one won't pass validation.

 We can't even call `get_form` with a dummy request object in the
 validation method, because it could call an overridden
 `get_readonly_fields` which assumes a real request object.

 And there are more bugs with the validation routine - for example if
 `get_readonly_fields` dynamically returns fields that don't exist, the
 validate routine won't catch it.

 Basically, I don't think we can do any static validation of
 `ModelAdmin.fieldsets` etc. against the form, because we don't know what
 form will actually be used, because it is defined and generated
 dynamically, not statically. I can't see a way of fixing this.

 BTW, I'm hitting this for my work on #19733.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20217: query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10

[Django]

#20217: query model using `filter` or `get` occur ValueError: invalid literal 
for
int() with base 10
-+-
 Reporter:  592280502@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  invalid
 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 russellm):

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


Comment:

 If you've got a question about how to fix an error, please post to the
 Django-users mailing list. Trac is a place where we log known bugs so we
 can make sure they're not forgotten.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20222: Some functions are wrapped into allow_lazy incorrectly

[Django]

#20222: Some functions are wrapped into allow_lazy incorrectly
---+--
 Reporter:  void   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by void):

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


Comment:

 Thanks to bmispelon for pointing that out.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20224: Documentation fix of allow_lazy usage example

[Django]

#20224: Documentation fix of allow_lazy usage example
--+
 Reporter:  void  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There is a line in the usage example of `allow_lazy`:
 `fancy_utility_function = allow_lazy(fancy_utility_function, unicode)`
 It would be better to use `six.text_type` instead of `unicode`, because
 `unicode` does not exist of python3

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20223: Allow allow_lazy to be used as a decorator

[Django]

#20223: Allow allow_lazy to be used as a decorator
-+
 Reporter:  void |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Utilities|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 `allow_lazy` cannot be used as a decorator for now, at least not in
 @-notation, because *resultclasses is required argument for this function.
 Decorator with arguments are functions, which accept arguments, returning
 function, which decorates source function. In allow_lazy signature
 arguments and function are mixed.
 So, proposal is to distinguish on type: if first argument of allow_lazy is
 of type `type`, then treat it like a three-def-decorator, while allowing
 current two-def-decorator behaviour if first argument is a function.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Django]

#3591: add support for custom app_label and verbose_name
--+
 Reporter:  jkocherhans   |Owner:  adrian
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 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:  1
--+

Comment (by malavon_despana@…):

 My suggestion: Let the developer declare in the application package's
 __init__.py something like:

 class Meta: #or whatever the name should be.
 verbose_name = _(u"App title for stuff like Admin")
 ... perhaps more stuff would be convenient here ...

 Keepin' seein' the raw name in the admin interface just sucks :(.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20222: Some functions are wrapped into allow_lazy incorrectly

[Django]

#20222: Some functions are wrapped into allow_lazy incorrectly
+
 Reporter:  void|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Utilities   |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 allow_lazy() requires more than one argument. Second and further arguments
 must be types.
 There are a few functions which are wrapped into allow_lazy without
 *resultclasses specified.
 Namely:
 * django.utils.html.strip_tags
 * django.utils.text.Truncator.chars
 * django.utils.text.Truncator.words
 * django.utils.text.recapitalize
 * django.utils.text.phone2numeric
 * django.utils.text.unescape_string_literal

 IPython session, which demonstrates code broken because of that:
 {{{
 In [1]: from django.utils.functional import lazy
 In [2]: from django.utils.encoding import force_text
 In [3]: from django.utils import six
 In [4]: from django.utils.html import strip_tags
 In [5]: promise = lazy(lambda:u'hello', six.text_type)()
 In [6]: force_text(promise)
 Out[6]: u'hello'
 In [7]: promise = lazy(lambda:u'hello', six.text_type)()
 In [8]: stripped = strip_tags(promise)
 In [9]: force_text(stripped)
 Out[9]: u''
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20147: Replace and deprecate request.META for HTTP headers

[Django]

#20147: Replace and deprecate request.META for HTTP headers
---+--
 Reporter:  lukeplant  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by lukeplant):

 There are a few more things that need considering if this is to be done:

 * `RequestFactory` and the test `Client`, and their APIs which pass
 directly to request.META.
 * `REMOTE_ADDRESS`, `REMOTE_USER`
 * `SECURE_PROXY_SSL_HEADER`

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] f69396: Fix admin_views tests after commit 3be368c73e.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f69396665c1dd3b6b70cc053f16403c66d57ce60
  
https://github.com/django/django/commit/f69396665c1dd3b6b70cc053f16403c66d57ce60
  Author: Baptiste Mispelon 
  Date:   2013-04-08 (Mon, 08 Apr 2013)

  Changed paths:
M tests/admin_views/tests.py

  Log Message:
  ---
  Fix admin_views tests after commit 3be368c73e.


  Commit: 7441a29f52046c96c072e1ae1f21d0be488b5a76
  
https://github.com/django/django/commit/7441a29f52046c96c072e1ae1f21d0be488b5a76
  Author: Jannis Leidel 
  Date:   2013-04-08 (Mon, 08 Apr 2013)

  Changed paths:
M tests/admin_views/tests.py

  Log Message:
  ---
  Merge pull request #1003 from bmispelon/fix-tests-3be368c73e

Fix admin_views tests after commit 3be368c73e.


Compare: https://github.com/django/django/compare/161c4da588d4...7441a29f5204

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
-+-
 Reporter:  mlavin   |Owner:  tobias
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carl Meyer ):

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


Comment:

 In [changeset:"161c4da588d4cc757da44bcbb5875a84a7b8a7e6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="161c4da588d4cc757da44bcbb5875a84a7b8a7e6"
 Fixed #14019 -- Initialize `SQLInsertCompiler.return_id` attribute.
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 161c4d: Fixed #14019 -- Initialize `SQLInsertCompiler.retu...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 161c4da588d4cc757da44bcbb5875a84a7b8a7e6
  
https://github.com/django/django/commit/161c4da588d4cc757da44bcbb5875a84a7b8a7e6
  Author: Tobias McNulty 
  Date:   2013-04-08 (Mon, 08 Apr 2013)

  Changed paths:
M django/db/models/sql/compiler.py
M tests/model_regress/tests.py

  Log Message:
  ---
  Fixed #14019 -- Initialize `SQLInsertCompiler.return_id` attribute.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
-+-
 Reporter:  mlavin   |Owner:  tobias
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tobias):

 The original pull request was against the unofficial Django repo on GitHub
 (and hence the link is broken), so I created a new one against the new
 repo that should apply cleanly (and the test passes, etc.):

 https://github.com/django/django/pull/1002

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #4136: NULL fields and Unique keys

[Django]

#4136: NULL fields and Unique keys
-+-
 Reporter:  David Cramer |Owner:
  |  aashu_dwivedi
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.3-rc
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

 * easy:  1 => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
-+-
 Reporter:  mlavin   |Owner:  tobias
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14019: SQLInsertCompiler.as_sql() failure

[Django]

#14019: SQLInsertCompiler.as_sql() failure
-+-
 Reporter:  mlavin   |Owner:  tobias
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carljm):

 Reopening after checking with Jacob on IRC. This is a code quality fix,
 and code quality matters in private APIs too.

 I don't like the patch using hasattr, but I think initializing `return_id`
 in `__init__` is a clear win.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20221: `conditional_escape` does not work with lazy strings

[Django]

#20221: `conditional_escape` does not work with lazy strings
---+-
 Reporter:  bmispelon  |Owner:  bmispelon
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 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 claudep):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 4a7292: Removed references to the DDN triage state.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4a7292df3be2338ff5d915a9ab3107067f662534
  
https://github.com/django/django/commit/4a7292df3be2338ff5d915a9ab3107067f662534
  Author: Aymeric Augustin 
  Date:   2013-04-08 (Mon, 08 Apr 2013)

  Changed paths:
M docs/internals/_images/triage_process.graffle
M docs/internals/_images/triage_process.pdf
M docs/internals/_images/triage_process.svg
M docs/internals/contributing/new-contributors.txt
M docs/internals/contributing/triaging-tickets.txt

  Log Message:
  ---
  Removed references to the DDN triage state.

Rephrased "How can I help with triaging?" a bit to reflect the current
practice.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20221: `conditional_escape` does not work with lazy strings

[Django]

#20221: `conditional_escape` does not work with lazy strings
---+--
 Reporter:  bmispelon  |Owner:  bmispelon
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  master
 Severity:  Normal |   Resolution:
 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 bmispelon):

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


Comment:

 I added some tests for `conditional_escape` and tried to make them pass.

 I think the `allow_lazy` decorator applied to `escape` was the issue here,
 so I removed and added some special-casing of `Promise` objects in the
 function itself.

 Here's the branch I'm working on:
 https://github.com/bmispelon/django/compare/ticket-20221

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20220: Problems with databases

[Django]

#20220: Problems with databases
-+-
 Reporter:  vallard.nyorx@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.5
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Problem with | Triage Stage:
  Databases  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20221: `conditional_escape` does not work with lazy strings

[Django]

#20221: `conditional_escape` does not work with lazy strings
+---
 Reporter:  bmispelon   |  Owner:  bmispelon
 Type:  Bug | Status:  new
Component:  Utilities   |Version:  master
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+---
 When passing the result of `ugettext_lazy` to `conditional_escape`, the
 result is not marked properly as safe which results in the data being
 escaped multiple times if `conditional_escape` is applied more than once.

 {{{
 #!python
 >>> from django.utils.html import conditional_escape
 >>> from django.utils.translation import ugettext_lazy
 >>>
 >>> s = ''
 >>> ss = ugettext_lazy(s)
 >>> conditional_escape(conditional_escape(s))
 'foo'
 >>> str(conditional_escape(conditional_escape(ss)))
 'lt;foogt;'
 }}}


 I ran into this issue by accident when working on #20211 where some old
 code had been left in and was escaping some strings twice in some cases.
 In that case, it was easy to work around the bug by simply removing the
 redundant calls to `conditional_escape`.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20220: Problems with databases

[Django]

#20220: Problems with databases
-+-
 Reporter:  vallard.nyorx@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  Problem with | Triage Stage:
  Databases  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20220: Problems with databases

[Django]

#20220: Problems with databases
-+
 Reporter:  vallard.nyorx@…  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Uncategorized|Version:  1.5
 Severity:  Normal   |   Keywords:  Problem with Databases
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Hello, I'm really sorry to send a message asking for assistance but I
 searched for over 4 hours ate the internet and here in the site and
 couldn't find anything.

 I'm following the https://docs.djangoproject.com/en/1.5/intro/tutorial01/
 at the part "Database setup" and no matter what I do I always get this
 error:

 OperationalError: (1049, "Unknown database "/home/user/Documents/My
 site'")


 I already re-installed mysql, phpmyadmin and django over 3 times and can't
 get this working. And tried with SQlite too but didn't work either,

 Sorry if I miss anything at the tutorial but I read everything more than
 10 times and couldn't find the answer.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #15610: Generic Foreign Keys break when used with multi-db.

[Django]

#15610: Generic Foreign Keys break when used with multi-db.
--+
 Reporter:  legutierr |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  master
 Severity:  Normal|   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 Dmitri Bogomolov <4glitch@…>):

 * cc: 4glitch@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10134: unique_for_* broken?

[Django]

#10134: unique_for_* broken?
-+-
 Reporter:  wdoekes  |Owner:  Alex
 Type:  Uncategorized|   Status:  closed
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  unique_for_date  | Triage Stage:  Ready for
  unique_for_month unique_for_year   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Please do not reopen bugs fixed 4 years ago. Create a new ticket where you
 can reference this one, 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #10134: unique_for_* broken?

[Django]

#10134: unique_for_* broken?
-+-
 Reporter:  wdoekes  |Owner:  Alex
 Type:  Uncategorized|   Status:  new
Component:  Forms|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  unique_for_date  | Triage Stage:  Ready for
  unique_for_month unique_for_year   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by monuszko):

 * status:  closed => new
 * severity:   => Normal
 * cc: monuszko (added)
 * needs_better_patch:  0 => 1
 * version:  master => 1.4
 * easy:   => 0
 * type:   => Uncategorized
 * ui_ux:   => 0
 * resolution:  fixed =>


Comment:

 I stumbled upon the same problem. I'm using Python 2.7.3 and Django
 1.4.5-1 from Debian repositories. I can add multiple entries with
 identical values and the admin interface doesn't complain. I tried with
 both 'slug' and 'title'.

 {{{

 # models.py

 from django.db import models

 from django.utils.timezone import now as utcnow
 now = utcnow() # replacing - date.now() causes problems with auto_now_add

 class Entry(models.Model):
 created_at = models.DateTimeField(default=now, editable=False)
 title  = models.CharField(max_length = 50)
 content= models.TextField()
 slug   = models.SlugField(unique_for_date='created_at')

 def __unicode__(self):
 return self.title
 class Meta:
 ordering = ['-created_at']

 # admin.py

 from news.models import Entry
 from django.contrib import admin

 class EntryAdmin(admin.ModelAdmin):
 prepopulated_fields = {'slug': ('title',)}

 list_filter = ['created_at']
 date_hierarchy = 'created_at'

 admin.site.register(Entry, EntryAdmin)

 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20147: Replace and deprecate request.META for HTTP headers

[Django]

#20147: Replace and deprecate request.META for HTTP headers
---+--
 Reporter:  lukeplant  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by lukeplant):

 As stated above, "Dictionary access should obey HTTP rules about case-
 sensitivity of the header names."

 I didn't say get rid of the transform - it should be done within the API,
 not by the user of the API. In terms of implementation,
 `request.HEADERS['Accept']` will map straight to
 `request._META['HTTP_ACCEPT']`, at least for wsgi, or do something
 equivalent that will ensure case-insensitivity.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20219: block evaluation preceeds if-statement evaluation

[Django]

#20219: block evaluation preceeds if-statement evaluation
-+--
 Reporter:  djangobug@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.4
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by aaugustin):

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


Comment:

 Conditionally overriding blocks isn't allowed (see previous tickets on
 this matter).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20157: Cannot pickle prefetched queryset on model with callable default datetime.datetime.now

[Django]

#20157: Cannot pickle prefetched queryset on model with callable default
datetime.datetime.now
-+-
 Reporter:  thomaspurchas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  pickle, queryset |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Just to make sure this wasn't missed somewhere, but by default, auth.user
 uses timezone.now which is exhibiting the same issues (for me) with trying
 to pickle it, even indirectly with vary headers in the cache.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20219: block evaluation preceeds if-statement evaluation

[Django]

#20219: block evaluation preceeds if-statement evaluation
-+
 Reporter:  djangobug@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I have a login page on my website that extends the base template. I a user
 is already logged in and visits the login page again, I want to show a
 notice saying that the user is already logged in.

 The base.html template contains a
 {{{
 {%block meta%}{%endblock%}
 }}}
 placeholder in the head of the html document.

 In the login page I added:
 {{{
 {%extends "base.html"%}
 {%if user and user.is_authenticated%}
   {%block meta%}
 
   {%endblock%}

   {%block content%}
   You are already logged in, etc.
   {%endblock%}
 {%else%}
   show the login form, etc
 {%endif%}
 }}}

 The problem is that even when I'm not logged in, the meta-tag is still
 inserted in the html page. This causes the login form to be refreshed
 continuously, making it impossible to log in.

 I have found a workaround: In the base template I placed an
 is_authenticated check around the meta block:
 {{{
 {%if user.is_authenticated%}
   {%block meta%}{%endblock%}
 {%else%}
   {%block meta_unauth%}{%endblock%}
 {%endif%}
 }}}

 This prevents the meta-tag from being placed on the page when the user is
 not authenticated (the meta block does not exist then).

 It seems to me that the evaluation of the block- and if-statements is not
 in the correct order in the template, but it is in the correct order in
 the base.html template.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20147: Replace and deprecate request.META for HTTP headers

[Django]

#20147: Replace and deprecate request.META for HTTP headers
---+--
 Reporter:  lukeplant  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 HTTP headers are case insensitive. You want to get rid of the transform,
 but what happens when someone sends "accept: " and you check for
 HEADERS["Accept"]?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6702: ModelForm: assert given instance is instance of model

[Django]

#6702: ModelForm: assert given instance is instance of model
--+
 Reporter:  guettli   |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by guettli):

 * cc: hv@… (removed)


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6702: ModelForm: assert given instance is instance of model

[Django]

#6702: ModelForm: assert given instance is instance of model
--+
 Reporter:  guettli   |Owner:
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by guettli):

 I was the author of this ticket five years ago. Now I think different
 about this: if type checking at runtime is done here, then there are some
 hundred other places where it could be done. This would sometimes help
 programmers new to django and python, . but it would slow down the
 execution time and make the code less clean. I think this ticket can be
 closed (without a modification to django), but since there where
 contributions by other people, I will leave this decision to you.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20209: fields is empty after post with RadioWidget

[Django]

#20209: fields is empty after post with RadioWidget
---+--
 Reporter:  strelnikovdmitrij  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by strelnikovdmitrij):

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


Comment:

 Hi,
 due to default choice at applicant gender it not raise issue,

 but if you will use instance for form, and your form will not be validated
 on post, the value of gender (which you choose before post) will not
 displayed with RadioSelect widget.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18098: order_with_respect_to should construct set_RELATED_order() method name from related_name

[Django]

#18098: order_with_respect_to should construct set_RELATED_order() method name 
from
related_name
-+-
 Reporter:  pressureman  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 We're getting rid of the DDN state, and this is a valid problem.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14018: Introduce class_plural %-substitution placeholder for related_name of ForeignKey/ManyToManyField

[Django]

#14018: Introduce class_plural %-substitution placeholder for related_name of
ForeignKey/ManyToManyField
-+-
 Reporter:  puxlit   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  related_name,|  decision needed
  ManyToManyField, ForeignKey,   |  Needs documentation:  0
  abstract base class|  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 I'm going to close this ticket, because it proposes to hardcode one
 specific case, rather than provide an API to resolve the general problem.

 There are several other [query:?status=!closed=~related_name
 tickets about related name] with more general proposals.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20111: Admin message levels are too ambigious

[Django]

#20111: Admin message levels are too ambigious
-+-
 Reporter:  darklow  |Owner:  darklow
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.5
Component:  contrib.admin|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  messages |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Kaspars Sprogis ):

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


Comment:

 In [changeset:"3be368c73e8e6696e7cc74421aeb4d06d8e828c8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3be368c73e8e6696e7cc74421aeb4d06d8e828c8"
 Fix #20111 Added more precise message level for succcess and warning
 messages
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 3be368: Fix #20111 Added more precise message level for su...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3be368c73e8e6696e7cc74421aeb4d06d8e828c8
  
https://github.com/django/django/commit/3be368c73e8e6696e7cc74421aeb4d06d8e828c8
  Author: Kaspars Sprogis 
  Date:   2013-04-08 (Mon, 08 Apr 2013)

  Changed paths:
M django/contrib/admin/actions.py
M django/contrib/admin/options.py

  Log Message:
  ---
  Fix #20111 Added more precise message level for succcess and warning messages


  Commit: ed576b69f9cc0202adbb82da778f1ff6036626b4
  
https://github.com/django/django/commit/ed576b69f9cc0202adbb82da778f1ff6036626b4
  Author: Jannis Leidel 
  Date:   2013-04-08 (Mon, 08 Apr 2013)

  Changed paths:
M django/contrib/admin/actions.py
M django/contrib/admin/options.py

  Log Message:
  ---
  Merge pull request #938 from darklow/ticket_20111

Added more precise message level for succcess and warning messages


Compare: https://github.com/django/django/compare/b5c0b3d1d932...ed576b69f9cc

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20111: Admin message levels are too ambigious

[Django]

#20111: Admin message levels are too ambigious
-+-
 Reporter:  darklow  |Owner:  darklow
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.5
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  messages |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by twoolie):

 * stage:  Accepted => Ready for checkin


Comment:

 I've looked over the patch. It's simple and solid. No tests/docs needed.

 Marking Ready For Checkin as per
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20218: Default authorization backend returns False when queried for object level permissions

[Django]

#20218: Default authorization backend returns False when queried for object 
level
permissions
---+
 Reporter:  soren@…|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5
 Severity:  Normal |   Keywords:  auth
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The default auth backend, django.contrib.auth.backends.ModelBackend
 unconditioally returns False when queried through User.has_perm() if
 has_perm is passed an object.

 I understand that erring on the side of caution is generally sound, but
 doing it this way forces generic consumers of the auth framework (e.g.
 Tastypie in my case) to know whether to pass an obj or not depending on
 the authentication backend chosen.  Always passing an obj to has_perm will
 result in all requests being denied if using the default backend. Not
 passing it makes it impossible to apply object level permissions even
 though I've configured a capable authz backend for this.

 Ticket #12462 suggests this is intentional, but doesn't give much of a
 rationale. It seems to me that if you don't want a user to be able to edit
 all objects of type XXX, don't give them the "app.change_XXX"?

 If this isn't considered a bug, can you offer some advice on how to deal
 with this situation from a generic application like Tastypie? How should
 it determine when to pass an obj or not?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20099: Allow filtering 404 reports by user agent

[Django]

#20099: Allow filtering 404 reports by user agent
---+
 Reporter:  coolRR |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by coolRR):

 ''Tumbleweed''

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20211: BoundField.label_tag now always escapes its `contents` parameter.

[Django]

#20211: BoundField.label_tag now always escapes its `contents` parameter.
-+-
 Reporter:  bmispelon|Owner:  bmispelon
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.5
 Severity:  Release blocker  |   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 bmispelon):

 * severity:  Normal => Release blocker
 * stage:  Ready for checkin => Accepted


Comment:

 I've discovered that the PR also inadvertently fixes a regression between
 1.4 and 1.5, where the label was escaped twice if it's a lazily-translated
 string (from ugettext_lazy).

 I've added another test to check for that behavior so I'm removing the RFC
 status.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20216: filtering over an Sum on a BooleanField uses BooleanField's get_db_prep_lookup on the value

[Django]

#20216: filtering over an Sum on a BooleanField uses BooleanField's
get_db_prep_lookup on the value
-+-
 Reporter:  Anossov  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  invalid
 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
-+-

Comment (by aaugustin):

 It's an accident of duck-typing that Avg works on boolean fields, and as
 said in my first comment, it certainly doesn't work on all databases.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20216: filtering over an Sum on a BooleanField uses BooleanField's get_db_prep_lookup on the value

[Django]

#20216: filtering over an Sum on a BooleanField uses BooleanField's
get_db_prep_lookup on the value
-+-
 Reporter:  Anossov  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  invalid
 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
-+-

Comment (by Anossov):

 This is just somewhat inconsistent — the docs say only numeric fields are
 allowed in Avg, but it is not enforced, and Avg works on BooleanFields
 because the result is always a FloatField. A mention in the Sum docs or an
 exception instead of undefined behaviour would be nice.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20217: query model using `filter` or `get` occur ValueError: invalid literal for int() with base 10

[Django]

#20217: query model using `filter` or `get` occur ValueError: invalid literal 
for
int() with base 10
--+
 Reporter:  592280502@…   |  Owner:  nobody
 Type:  Bug   | 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
--+
 class User(models.Model):
 identifier=models.CharField(max_length=128, unique=True,
 db_index=True)
 ..
 ..

 class Token(models.Model):
 user = models.ForeignKey("User", related_name="Tokens")
 token_string = models.CharField(max_length=128, unique=True,
 db_index=True)

 while I already have a tk(),I run this:
 user = User.objects.filter(id=tk.user_id) if user: user = user[0]
 it cause the ValueError: invalid literal for int() with base 10:
 File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 113, in __nonzero__
 iter(self).next()
   File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 107, in _result_iter
 self._fill_cache()
   File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 772, in _fill_cache
 self._result_cache.append(self._iter.next())
   File "/usr/local/lib/python2.7/site-packages/django/db/models/query.py",
 line 273, in iterator
 for row in compiler.results_iter():
   File "/usr/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 680, in results_iter
 for rows in self.execute_sql(MULTI):
   File "/usr/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 735, in execute_sql
 cursor.execute(sql, params)
   File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/mysql/base.py", line 86, in execute
 return self.cursor.execute(query, args)
   File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 174, in
 execute
 self.errorhandler(self, exc, value)
   File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 36, in
 defaulterrorhandler
 raise errorclass, errorvalue
 ValueError: invalid literal for int() with base 10: '\xd9'
 but it disappeared when I restart my project, but a couple of days while
 running, it occured again
 How does it happened and any solutions?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20216: filtering over an Sum on a BooleanField uses BooleanField's get_db_prep_lookup on the value

[Django]

#20216: filtering over an Sum on a BooleanField uses BooleanField's
get_db_prep_lookup on the value
-+-
 Reporter:  Anossov  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  invalid
 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 aaugustin):

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


Comment:

 In general, aggregation only works when the result of the aggregate has
 the same type as the original value.

 Arithmetic on booleans doesn't make sense, even though Python attemps to
 perform it:

 {{{
 >>> bool(True - True)
 False
 >>> bool(True / False)
 Traceback (most recent call last):
   File "", line 1, in 
 ZeroDivisionError: integer division or modulo by zero
 }}}

 Specifically, your code won't work on databases where true and false are
 stored as `'t'` and `'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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.