[Django] #29332: AdminReadOnly field accepts the optional argument model_admin but treats it as non-optional

[Django]

#29332: AdminReadOnly field accepts the optional argument model_admin but 
treats it
as non-optional
-+
   Reporter:  Josh DM|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Using a FieldSet without providing a `model_admin` results in an error
 since AdminReadOnly calls: `model_admin.get_empty_value_display()`.

 My expected behaviour is that it does not error, and sets the
 `empty_value_display` to the empty string.
 Relevant file:
 https://github.com/django/django/blob/master/django/contrib/admin/helpers.py

 Cheers.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.2e524d4e7d588929a6a53d6472a8f370%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29331: Model fields where the field name is shadowed by Python property aren't saved

[Django]

#29331: Model fields where the field name is shadowed by Python property aren't
saved
-+-
 Reporter:  Ben Mathes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models,  | Triage Stage:  Accepted
  deferred_field, save   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 FWIW adjusting your descriptor to use `__dict__['field']` instead of
 `__dict__['_field']` should work just fine.


 {{{#!python
 class SomeModel(models.Model):
 """
 a contrived model field where we want a "field" that is stored
 in a "field" column, but we use @property getter/setters so
 we name the SomeModel class's attribute as "_field".
 """
 name = models.TextField(null=True)
 _field = models.TextField(name="field")

 @property
 def field(self):
 return self.__dict__['field'].upper()

 @field.setter
 def field(self, new_value):
 self.__dict__['field'] = new_value.lower()
 }}}

 I don't think we can change the assumption that `name` either set
 implicitly or explicitly through a parameter  the will be present in
 `__dict__` without breaking a lot of stuff.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2052f918bfa63e54b7cef30a6390c49c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29331: Model fields where the field name is shadowed by Python property aren't saved

[Django]

#29331: Model fields where the field name is shadowed by Python property aren't
saved
-+-
 Reporter:  Ben Mathes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models,  | Triage Stage:  Accepted
  deferred_field, save   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ben Mathes):

 I suspect this is related, since the root cause is a change in
 {{{get_deferred_attributes}}}

 https://github.com/jpwatts/django-positions/issues/49

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.00bcf14ed03291edb4fe47e4b5769ba1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29331: Model fields where the field name is shadowed by Python property aren't saved

[Django]

#29331: Model fields where the field name is shadowed by Python property aren't
saved
-+-
 Reporter:  Ben Mathes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models,  | Triage Stage:  Accepted
  deferred_field, save   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ben Mathes):

 We're working around it in our specific use case, but not a general
 solution. Possible the codebase where we found this was mistaking
 {{{name}}} for {{{db_column}}}, as setting the {{{name}}} kwarg does seem
 to set the DB column name.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.16a923b7f3d3addf39995365df2a7bf7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29281: In some cases i18n set_language does not change url language

[Django]

#29281: In some cases i18n set_language does not change url language
-+-
 Reporter:  Nikita Delyukov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 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 Tim Graham):

 A test for `tests/view_tests/tests/test_i18n.py` that demonstrates the
 issue would be great.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.78d8a4aaa53c70c965511c7e6162b9ec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29317: filter keyword undocumented in PostgreSQL aggregate functions

[Django]

#29317: filter keyword undocumented in PostgreSQL aggregate functions
--+
 Reporter:  Matthew Pava  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:
 Severity:  Normal|   Resolution:
 Keywords:  aggregate | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.dad8f3c292467889cde519171f160abe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29331: Model fields where the field name is shadowed by Python property aren't saved (was: Model fields where the python attribute name does not match the db column are not saved)

[Django]

#29331: Model fields where the field name is shadowed by Python property aren't
saved
-+-
 Reporter:  Ben Mathes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models,  | Triage Stage:  Accepted
  deferred_field, save   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_tests:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 That's interesting, I didn't know about the `name` argument to `Field`. Is
 it documented? The last issue I found for it was #14695.

 I'm not sure if this can be fixed. Do you plan to offer a patch? If not, I
 suppose the restriction could at least be documented.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f8bc1cfe015bd661c5ddffdf0c296cf0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29175: makemessages does parse ES6 template strings

[Django]

#29175: makemessages does parse ES6 template strings
--+
 Reporter:  Artem Skoretskiy  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 That looks okay. I create a [https://github.com/django/django/pull/9880
 PR]. One comment there.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6e9f71208ca0b6ac2231a9c8a7c89260%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29331: Model fields where the python attribute name does not match the db column are not saved

[Django]

#29331: Model fields where the python attribute name does not match the db 
column
are not saved
-+-
 Reporter:  Ben Mathes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models,  | Triage Stage:
  deferred_field, save   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ben Mathes:

Old description:

> When defining a model, if you rename a model's db column, django will
> thing that model is deferred and will not {{{save()}}} it.
>
> e.g.
> {{{
> class SomeModel(models.Model):
> """
> a contrived model field where we want a "field" that is stored
> in a "field" column, but we use @property getter/setters so
> we name the SomeModel class's attribute as "_field".
> """
> name = models.TextField(null=True)
> _field = models.TextField(name="field")
>
> @property
> def field(self):
> return self._field.upper()
>
> @field.setter
> def field(self, new_value):
> self._field = new_value.lower()
> }}}
>

>
> With a renamed db column, {{{"_field"}}} is in {{{self.__dict__}}}, but
> {{{"field"}}} is not,
>

> {{{
>
>  def get_deferred_fields(self):
>  """
>  Return a set containing names of deferred fields for this instance.
>  """
>  return {
>  f.attname for f in self._meta.concrete_fields
>  if f.attname not in self.__dict__
>  }
> }}}
>
> So {{{field}}} is not saved in {{{.save()}}}, because django _mistakenly_
> thinks {{{"field"}}} is deferred, so it is ignored during {{{.save()}}}
>
> {{{
> #
> https://github.com/django/django/blob/93331877c81c1c6641b163b97813268f483ede4b/django/db/models/base.py#L712
> # ...
> # elif not force_insert and deferred_fields and using ==
> self._state.db:
> # field_names = set()
> # for field in self._meta.concrete_fields:
> # if not field.primary_key and not hasattr(field, 'through'):
> # field_names.add(field.attname)
> # ->  loaded_fields = field_names.difference(deferred_fields)
> # if loaded_fields:
> # update_fields = frozenset(loaded_fields)
> #
> # self.save_base(using=using, force_insert=force_insert,
> #force_update=force_update,
> update_fields=update_fields)
> # ...
> }}}
>

> Reproduced in this github django repo:
> https://github.com/benmathes/deferred_fields_bug

New description:

 Reproduced in this github django repo:
 https://github.com/benmathes/deferred_fields_bug


 When defining a model, if you rename a model's db column, django will
 thing that model is deferred and will not {{{save()}}} it.

 e.g.
 {{{
 class SomeModel(models.Model):
 """
 a contrived model field where we want a "field" that is stored
 in a "field" column, but we use @property getter/setters so
 we name the SomeModel class's attribute as "_field".
 """
 name = models.TextField(null=True)
 _field = models.TextField(name="field")

 @property
 def field(self):
 return self._field.upper()

 @field.setter
 def field(self, new_value):
 self._field = new_value.lower()
 }}}



 With a renamed db column, {{{"_field"}}} is in {{{self.__dict__}}}, but
 {{{"field"}}} is not,


 {{{

  def get_deferred_fields(self):
  """
  Return a set containing names of deferred fields for this instance.
  """
  return {
  f.attname for f in self._meta.concrete_fields
  if f.attname not in self.__dict__
  }
 }}}

 So {{{field}}} is not saved in {{{.save()}}}, because django _mistakenly_
 thinks {{{"field"}}} is deferred, so it is ignored during {{{.save()}}}

 {{{
 #
 
https://github.com/django/django/blob/93331877c81c1c6641b163b97813268f483ede4b/django/db/models/base.py#L712
 # ...
 # elif not force_insert and deferred_fields and using ==
 self._state.db:
 # field_names = set()
 # for field in self._meta.concrete_fields:
 # if not field.primary_key and not hasattr(field, 'through'):
 # field_names.add(field.attname)
 # ->  loaded_fields = field_names.difference(deferred_fields)
 # if loaded_fields:
 # update_fields = frozenset(loaded_fields)
 #
 # self.save_base(using=using, force_insert=force_insert,
 #force_update=force_update,
 update_fields=update_fields)
 # ...
 }}}


 Reproduced in this github django repo:
 

Re: [Django] #29331: Model fields where the python attribute name does not match the db column are not saved

[Django]

#29331: Model fields where the python attribute name does not match the db 
column
are not saved
-+-
 Reporter:  Ben Mathes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models,  | Triage Stage:
  deferred_field, save   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ben Mathes:

Old description:

> When defining a model, if you rename a model's db column, django will
> thing that model is deferred and will not {{{save()}}} it.
>
> e.g.
> {{{
> class SomeModel(models.Model):
> """
> a contrived model field where we want a "field" that is stored
> in a "field" column, but we use @property getter/setters so
> we name the SomeModel class's attribute as "_field".
> """
> name = models.TextField(null=True)
> _field = models.TextField(name="field")
>
> @property
> def field(self):
> return self._field.upper()
>
> @field.setter
> def field(self, new_value):
> self._field = new_value.lower()
> }}}
>

>
> With a renamed db column, {{{"_field"}} is in {{{self.__dict__}}}, but
> {{{"field"}}} is not,
>

> {{{
>
>  def get_deferred_fields(self):
>  """
>  Return a set containing names of deferred fields for this instance.
>  """
>  return {
>  f.attname for f in self._meta.concrete_fields
>  if f.attname not in self.__dict__
>  }
> }}}
>
> So {{{field}}} is not saved in {{{.save()}}}, because django _mistakenly_
> thinks {{{"field"}}} is deferred, so it is ignored during {{{.save()}}}
>
> {{{
> #
> https://github.com/django/django/blob/93331877c81c1c6641b163b97813268f483ede4b/django/db/models/base.py#L712
> # ...
> # elif not force_insert and deferred_fields and using ==
> self._state.db:
> # field_names = set()
> # for field in self._meta.concrete_fields:
> # if not field.primary_key and not hasattr(field, 'through'):
> # field_names.add(field.attname)
> # ->  loaded_fields = field_names.difference(deferred_fields)
> # if loaded_fields:
> # update_fields = frozenset(loaded_fields)
> #
> # self.save_base(using=using, force_insert=force_insert,
> #force_update=force_update,
> update_fields=update_fields)
> # ...
> }}}
>

> Reproduced in this github django repo:
> https://github.com/benmathes/deferred_fields_bug

New description:

 When defining a model, if you rename a model's db column, django will
 thing that model is deferred and will not {{{save()}}} it.

 e.g.
 {{{
 class SomeModel(models.Model):
 """
 a contrived model field where we want a "field" that is stored
 in a "field" column, but we use @property getter/setters so
 we name the SomeModel class's attribute as "_field".
 """
 name = models.TextField(null=True)
 _field = models.TextField(name="field")

 @property
 def field(self):
 return self._field.upper()

 @field.setter
 def field(self, new_value):
 self._field = new_value.lower()
 }}}



 With a renamed db column, {{{"_field"}}} is in {{{self.__dict__}}}, but
 {{{"field"}}} is not,


 {{{

  def get_deferred_fields(self):
  """
  Return a set containing names of deferred fields for this instance.
  """
  return {
  f.attname for f in self._meta.concrete_fields
  if f.attname not in self.__dict__
  }
 }}}

 So {{{field}}} is not saved in {{{.save()}}}, because django _mistakenly_
 thinks {{{"field"}}} is deferred, so it is ignored during {{{.save()}}}

 {{{
 #
 
https://github.com/django/django/blob/93331877c81c1c6641b163b97813268f483ede4b/django/db/models/base.py#L712
 # ...
 # elif not force_insert and deferred_fields and using ==
 self._state.db:
 # field_names = set()
 # for field in self._meta.concrete_fields:
 # if not field.primary_key and not hasattr(field, 'through'):
 # field_names.add(field.attname)
 # ->  loaded_fields = field_names.difference(deferred_fields)
 # if loaded_fields:
 # update_fields = frozenset(loaded_fields)
 #
 # self.save_base(using=using, force_insert=force_insert,
 #force_update=force_update,
 update_fields=update_fields)
 # ...
 }}}


 Reproduced in this github django repo:
 https://github.com/benmathes/deferred_fields_bug

--

-- 
Ticket URL: 

Re: [Django] #29331: Model fields where the python attribute name does not match the db column are not saved

[Django]

#29331: Model fields where the python attribute name does not match the db 
column
are not saved
-+-
 Reporter:  Ben Mathes   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models,  | Triage Stage:
  deferred_field, save   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ben Mathes):

 * 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 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.734e64eb861579ae68d327663fcb6b48%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29331: Model fields where the python attribute name does not match the db column are not saved

[Django]

#29331: Model fields where the python attribute name does not match the db 
column
are not saved
-+-
   Reporter:  Ben|  Owner:  nobody
  Mathes |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.0
  layer (models, ORM)|   Keywords:  models,
   Severity:  Normal |  deferred_field, save
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When defining a model, if you rename a model's db column, django will
 thing that model is deferred and will not {{{save()}}} it.

 e.g.
 {{{
 class SomeModel(models.Model):
 """
 a contrived model field where we want a "field" that is stored
 in a "field" column, but we use @property getter/setters so
 we name the SomeModel class's attribute as "_field".
 """
 name = models.TextField(null=True)
 _field = models.TextField(name="field")

 @property
 def field(self):
 return self._field.upper()

 @field.setter
 def field(self, new_value):
 self._field = new_value.lower()
 }}}



 With a renamed db column, {{{"_field"}} is in {{{self.__dict__}}}, but
 {{{"field"}}} is not,


 {{{

  def get_deferred_fields(self):
  """
  Return a set containing names of deferred fields for this instance.
  """
  return {
  f.attname for f in self._meta.concrete_fields
  if f.attname not in self.__dict__
  }
 }}}

 So {{{field}}} is not saved in {{{.save()}}}, because django _mistakenly_
 thinks {{{"field"}}} is deferred, so it is ignored during {{{.save()}}}

 {{{
 #
 
https://github.com/django/django/blob/93331877c81c1c6641b163b97813268f483ede4b/django/db/models/base.py#L712
 # ...
 # elif not force_insert and deferred_fields and using ==
 self._state.db:
 # field_names = set()
 # for field in self._meta.concrete_fields:
 # if not field.primary_key and not hasattr(field, 'through'):
 # field_names.add(field.attname)
 # ->  loaded_fields = field_names.difference(deferred_fields)
 # if loaded_fields:
 # update_fields = frozenset(loaded_fields)
 #
 # self.save_base(using=using, force_insert=force_insert,
 #force_update=force_update,
 update_fields=update_fields)
 # ...
 }}}


 Reproduced in this github django repo:
 https://github.com/benmathes/deferred_fields_bug

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.fec07e6d4bd5e65bedb0024d25604826%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29253: method_decorator() with list argument doesn't copy over attributes of the decorator function

[Django]

#29253: method_decorator() with list argument doesn't copy over attributes of 
the
decorator function
+--
 Reporter:  Chris Jerdonek  |Owner:  Chris Jerdonek
 Type:  Bug |   Status:  closed
Component:  Utilities   |  Version:  2.0
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  decorators  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"fdc936c9130cf4fb5d59869674b9a31cc79a7999" fdc936c]:
 {{{
 #!CommitTicketReference repository=""
 revision="fdc936c9130cf4fb5d59869674b9a31cc79a7999"
 Fixed #29253 -- Made method_decorator(list) copy attributes.
 }}}

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.23e4feeedeba058287c59a00f4a336a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29318: ValidationError has no attribute `error_list` if message is a dict, but Field.run_validators() depends on it

[Django]

#29318: ValidationError has no attribute `error_list` if message is a dict, but
Field.run_validators() depends on it
---+--
 Reporter:  Michael Käufl  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  master
 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 Tim Graham):

 * status:  new => closed
 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8fc741679204b18d2bd87f6bf61a5910%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29329: Inconsistent datetime logging from runserver.

[Django]

#29329: Inconsistent datetime logging from runserver.
--+
 Reporter:  Sjoerd Job Postmus|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  2.0
 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 Tim Graham):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Core (Other)
 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.cb52d760e78459ab90bb7423d03a86dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29175: makemessages does parse ES6 template strings

[Django]

#29175: makemessages does parse ES6 template strings
--+
 Reporter:  Artem Skoretskiy  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.0
 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 Claude Paroz):

 * has_patch:  0 => 1


Comment:

 Draft patch attached for resolving both #29175 and #29174.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.79746625c1b3798913c90466e69d92d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29175: makemessages does parse ES6 template strings

[Django]

#29175: makemessages does parse ES6 template strings
--+
 Reporter:  Artem Skoretskiy  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  2.0
 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 Claude Paroz):

 * Attachment "29174.diff" added.

 Tentative doc patch

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.96d2915fbd3e11102aa98429902735c3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24342: Add EnumField model/form fields

[Django]

#24342: Add EnumField model/form fields
-+-
 Reporter:  Thomas Stephenson|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Krzysztof Szularz):

 * cc: Krzysztof Szularz (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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.89ed2f9242a35e1c801a24b9d735edec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29323: HTTPRequest QueryDict wrongly decodes binary encoded values

[Django]

#29323: HTTPRequest QueryDict wrongly decodes binary encoded values
-+--
 Reporter:  Thomas Riccardi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 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 Simon Charette):

 Is there a reason you can't base64 encode your binary content instead? It
 should be easy to turn it into bytes when necessary after that.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.b9c7035a1cbca405ffb89e878f701b0c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29274: Update the password list used by CommonPasswordValidator to a more recent list

[Django]

#29274: Update the password list used by CommonPasswordValidator to a more 
recent
list
-+-
 Reporter:  Brenton Cleeland |Owner:  Jessica
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  CommonPasswordValidator|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"93331877c81c1c6641b163b97813268f483ede4b" 9333187]:
 {{{
 #!CommitTicketReference repository=""
 revision="93331877c81c1c6641b163b97813268f483ede4b"
 Fixed #29274 -- Increased the number of common passwords from 1k to 20k.
 }}}

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.785e3d7b61fef25b3ec6a19a88f3b36b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29330: Regression in master: cannot pickle queryset with expression

[Django]

#29330: Regression in master: cannot pickle queryset with expression
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"60156750f66fe9e8b95067654b292f12a055393c" 60156750]:
 {{{
 #!CommitTicketReference repository=""
 revision="60156750f66fe9e8b95067654b292f12a055393c"
 Fixed #29330 -- Fixed crash when pickling BaseExpression.

 Regression in cfff2af02be40106d4759cc6f8bfa476ce82421c.
 }}}

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.fff7a598e463d07ef925186464e76f12%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29329: Inconsistent datetime logging from runserver.

[Django]

#29329: Inconsistent datetime logging from runserver.
-+-
 Reporter:  Sjoerd Job Postmus   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  2.0
 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 Tim Graham):

 * component:  Uncategorized => Core (Other)
 * type:  Uncategorized => Cleanup/optimization


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1ecfbaf3f3d3a3a39094566e3f41a164%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29323: HTTPRequest QueryDict wrongly decodes binary encoded values

[Django]

#29323: HTTPRequest QueryDict wrongly decodes binary encoded values
-+--
 Reporter:  Thomas Riccardi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 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 Tim Graham):

 Can you explain the use case for encoding bytes this way?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.0a7942b61b83f73b842dcd70cae5923c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29330: Regression in master: cannot pickle queryset with expression

[Django]

#29330: Regression in master: cannot pickle queryset with expression
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c6b79ee9d79e85be8c624e2c69c014e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29259: Disable Fuzzy

[Django]

#29259: Disable Fuzzy
-+-
 Reporter:  Mostafa Zeinivand|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  2.0
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
  fuzzy,translation,locale,internationalization|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

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


Comment:

 See https://docs.djangoproject.com/en/2.0/topics/i18n/translation
 /#customizing-makemessages and use `msgmerge_options` instead of
 `xgettext_options`.

 Please do not reopen tickets without giving any justification.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.334ae2388984fdfd7324e0727faae1f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29259: Disable Fuzzy

[Django]

#29259: Disable Fuzzy
-+-
 Reporter:  Mostafa Zeinivand|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  2.0
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  fuzzy,translation,locale,internationalization|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mostafa Zeinivand):

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


-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.2e68a34f4c4f220868c3bf887b3f4bd4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29330: Regression in master: cannot pickle queryset with expression

[Django]

#29330: Regression in master: cannot pickle queryset with expression
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Daniel Miller):

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

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ff726c2d500636c2687fca1bd7874ed4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29323: HTTPRequest QueryDict wrongly decodes binary encoded values (was: HTTPRequest QueryDict wrongly decodes binary encoded values in python2)

[Django]

#29323: HTTPRequest QueryDict wrongly decodes binary encoded values
-+--
 Reporter:  Thomas Riccardi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 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 Thomas Riccardi):

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


Old description:

> `application/x-www-form-urlencoded` bodies allow binary values: just
> percent-escape (most of) the bytes.
>
> It doesn't work with python2 and django.
>
> In python2, QueryDict returns an `unicode` string for values, which makes
> it impossible to represent binary data.
> Worse: it returns an `unicode` string whose unicode code points are the
> raw expected bytes (caused by lax behavior of `str.decode('iso-8859-1')`)
> so it silently fails.
>
> Example:
> {{{#!python
> q = QueryDict('foo=%00%7f%80%ff')
> q['foo']
> # actual:
> # u'\x00\x7f\x80\xff'
> # expected:
> # '\x00\x7f\x80\xff'
> }}}
>
> Relevant code:
> https://github.com/django/django/blob/f89b11b879b83aa505dc8231da5f06ca4b1b062e/django/http/request.py#L397-L401
>
> This was introduced by
> https://github.com/django/django/commit/fa02120d360387bebbbe735e86686bb4c7c43db2
> while trying to accept broken user agents that send non-ascii as
> urlencoded raw values:
> - the python 3 version seems fine: it tries to decode '''before'''
> calling the query string parser (from `urllib`)
> - the python 2 version made a mistake: it decodes '''after''' calling the
> query string parser (and only on the value, not the key strangely)
>

> I'm not sure how to fix this, as there are many locations where the key
> and value are re-encoded (`appendlist` does it too..)
>

> I have not (yet) tested with python3.

New description:

 `application/x-www-form-urlencoded` bodies allow binary values: just
 percent-escape (most of) the bytes.

 It doesn't work with python2 and django.

 In python2, QueryDict returns an `unicode` string for values, which makes
 it impossible to represent binary data.
 Worse: it returns an `unicode` string whose unicode code points are the
 raw expected bytes (caused by lax behavior of `str.decode('iso-8859-1')`)
 so it silently fails.

 Example:
 {{{#!python
 q = QueryDict('foo=%00%7f%80%ff')
 q['foo']
 # actual:
 # u'\x00\x7f\x80\xff'
 # expected:
 # '\x00\x7f\x80\xff'
 }}}

 Relevant code:
 
https://github.com/django/django/blob/f89b11b879b83aa505dc8231da5f06ca4b1b062e/django/http/request.py#L397-L401

 This was introduced by
 
https://github.com/django/django/commit/fa02120d360387bebbbe735e86686bb4c7c43db2
 while trying to accept broken user agents that send non-ascii as
 urlencoded raw values:
 - the python 3 version seems fine: it tries to decode '''before''' calling
 the query string parser (from `urllib`)
 - the python 2 version made a mistake: it decodes '''after''' calling the
 query string parser (and only on the value, not the key strangely)


 I'm not sure how to fix this, as there are many locations where the key
 and value are re-encoded (`appendlist` does it too..)


 In python 3 it fails too, but probably only because of the forced post-
 query-string-parser decoding into unicode string: to support binary values
 we don't want decoding at this point.

 A test for python3:
 {{{#!python
 def test_binary_input(self):
 """
 QueryDicts must be able to handle binary.
 """
 q = QueryDict(b'foo=%00%7f%80%ff')
 self.assertListEqual(list(map(ord, q['foo'])), [0x00, 0x7F, 0x80,
 0xFF])
 }}}
 {{{
 AssertionError: Lists differ: [0, 127, 65533, 65533] != [0, 127, 128, 255]

 First differing element 2:
 65533
 128

 - [0, 127, 65533, 65533]
 + [0, 127, 128, 255]
 }}}

--

Comment:

 OK.

 I tested with python3 and it breaks too, but only because the code
 explicitly tries to generates an unicode string (`bytes_to_text` in
 `appendlist`).

 I updated the description to also add the python3 test.

 To support binary we would need to add an explicit option to get the
 `bytes` (maybe an encoding that asks to keep `bytes`?); not sure how to
 expose it in `HTTPRequest`.

-- 
Ticket URL: 
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 

[Django] #29330: Regression in master: cannot pickle queryset with expression

[Django]

#29330: Regression in master: cannot pickle queryset with expression
-+-
   Reporter:  Daniel |  Owner:  nobody
  Miller |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Removal of `BaseExpression.__getstate__` in
 [https://github.com/django/django/pull/9134#pullrequestreview-112057277 PR
 9134] caused querysets with expressions derived from `BaseExpression` to
 no longer be pickle-able.

 Error:

 {{{
 Traceback (most recent call last):
   File "/home/travis/build/millerdev/django-cte/tests/test_recursive.py",
 line 212, in test_pickle_recursive_cte_queryset
 pickled_qs = pickle.loads(pickle.dumps(regions))
 AttributeError: Can't pickle local object
 'BaseExpression.convert_value..'
 }}}

 Seen here: https://travis-ci.org/millerdev/django-cte/jobs/366128465

 Steps to reproduce:

 - Clone [https://github.com/dimagi/django-cte django-cte]
 - Make a virtualenv any way you prefer.
 - `pip install git+https://github.com/django/django.git@master` (or
 however you prefer to install django master).
 - `pip install nose `
 - `nosetests
 tests.test_recursive:TestRecursiveCTE.test_pickle_recursive_cte_queryset`
 - Observe pickle error.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.9bdb4760aa8a1a4b5a7f60f741c29de3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29329: Inconsistent datetime logging from runserver.

[Django]

#29329: Inconsistent datetime logging from runserver.
--+
   Reporter:  Sjoerd Job Postmus  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  2.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 In Django 1.11 and higher, the runserver logging can sometimes be
 inconsistent.

 {{{
 [16/Apr/2018 13:32:35] "GET /some/local/url HTTP/1.1" 200 7927
 [2018-04-16 13:32:35,745] - Broken pipe from ('127.0.0.1', 57570)
 }}}

 This is because logging from `WSGIRequestHandler` uses `server_time` as
 calculated using `BaseHTTPServer.log_date_time_string`. On the other hand,
 `WSGIServer` uses logging without providing a `server_time`. This gets
 "fixed" in `ServerFormatter.format` using `self.formatTime(record,
 self.datefmt)`, which uses a completely different format.

 Currently we make this at least consistent by providing the `datefmt`
 parameter when constructing the logger, but it would be better if they
 were coded to be in sync (and configurable?).

 (Looking into it further, it looks like we should be using `%(asctime)s`
 instead of `%(server_time)s`, but would be good if that were the suggested
 default. In https://docs.djangoproject.com/en/2.0/releases/1.10
 /#runserver-output-goes-through-logging we see `%(server_time)s`.)

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.8f66c85a97d6f5a42106e148a12fc281%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28600: Add prefetch related support to RawQuerySet

[Django]

#28600: Add prefetch related support to RawQuerySet
-+-
 Reporter:  Adnan Umer   |Owner:  Adnan
 |  Umer
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Adnan Umer):

 * needs_better_patch:  1 => 0


Comment:

 Did requested changes. Requesting to review the PR again.

-- 
Ticket URL: 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.3e4edef352844c3472d6d2ea93bff0ab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.