Re: [Django] #22449: Colorize output of test results

[Django]

#22449: Colorize output of test results
-+-
 Reporter:  Jake Rothenbuhler|Owner:  Yuri
 |  Shikanov
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 FWIW, I agree with Tim. Also, the proposed implementation seems to tightly
 couple much of Django's test harness with the idea of coloring. For
 example, `DebugSQLTextTestResult` now inherits from
 `ColoredTextTestResult` when conceptually debugging SQL should be
 orthogonal to coloring. I would rather see a looser coupling (e.g. making
 it easier to "plug" coloring in through appropriate hooks or composition,
 etc.) rather than making the class hierarchies even heavier weight.

-- 
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/071.51dd1b96f6ee6c3624df4529cfa8fe1c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29181: Move `flatten` to utils

[Django]

#29181: Move `flatten` to utils
-+
   Reporter:  Daniel Hahler  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  master
   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  |
-+
 I think `flatten` from `django.contrib.admin.utils` should be moved to
 `django.utils`, and get modernized to not only handle nested lists and
 tuples.

 I've tried to use it with django/forms/widgets.py, but it caused an
 recursive import issue.

 Where should it go?  django/utils/functional.py

-- 
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/050.f1a15d324cbecdb5c2c7269b4a7295a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22449: Colorize output of test results

[Django]

#22449: Colorize output of test results
-+-
 Reporter:  Jake Rothenbuhler|Owner:  Yuri
 |  Shikanov
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I'm not sure that including this in Django is a good idea. In particular,
 copying entire parts of Python like `TextTestRunner.run()` could be a
 maintenance headache. I found some third party solutions like
 [https://github.com/django/django/pull/9688 redgreenunittests] (which does
 the same I guess, but since it's a separate package, it can adapt more
 quickly than Django can).

 Colorizing test results sounds more like something that Python should
 allow rather than a problem that Django should solve.

-- 
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/071.b6d2b484c50916b2a664d14c74c2b583%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25718: Can’t use queries with JSON ’null’ values with JSONField

[Django]

#25718: Can’t use queries with JSON ’null’ values with JSONField
-+-
 Reporter:  Dmitry Dygalo|Owner:  Dmitry
 |  Dygalo
 Type:  Bug  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Looking good, but I think `HStoreField` should have the same behavior.

-- 
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/070.113e13dec5f5728e1e89cd3d652e4250%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Flavio Curella):

 To elaborate: the only reason I think it should support both list and
 tuples is because we have other places where we do so: for example,
 {{{Meta.ordering}}} comes to mind.

 But I'm with you if you'd rather not persevere with that pattern, and push
 the user to use {{{tuples}}} whenever possible.

-- 
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.a0f5d4d9865f3eaaef087021b1ed0248%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Flavio Curella):

 @Tim Graham: I think we can just link
 https://github.com/django/django/pull/9368 to this ticket and use it as it
 is

-- 
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.1af4adb98e775a481e090a05d5c82f40%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Marc Kirkwood):

 * owner:  Marc Kirkwood => (none)
 * status:  assigned => new


-- 
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.38cbea6e08df10df2028790cbf6cd649%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  Marc
 Type:   |  Kirkwood
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Marc Kirkwood):

 Replying to [comment:4 Flavio Curella]: I agree with that; looks like the
 PR you linked to solves the problem better.

-- 
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.34cff946d846d4d5c7a5c94ba650%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  Marc
 Type:   |  Kirkwood
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Flavio Curella):

 I think it should It should accept a list or a tuple as in
 https://github.com/django/django/pull/9368

 Re: defaulting to {{{()}}} vs defaulting to {{{None}}}, I don't really
 have a strong opinion. I'm used to see the {{{arg=None}}} pattern more
 often, but that could just be cargo-culting.

-- 
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.d5291ce611d314faeb29b2adaa8ad44f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  Marc
 Type:   |  Kirkwood
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Marc Kirkwood):

 * owner:  nobody => Marc Kirkwood
 * status:  new => assigned


-- 
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.1d55aa16c989cef751ab3130c692b391%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29133: call_command() fails if a required option is passed in via **options

[Django]

#29133: call_command() fails if a required option is passed in via **options
-+-
 Reporter:  Alex Tomic   |Owner:  Alex
 Type:   |  Tomic
  Cleanup/optimization   |   Status:  closed
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"a1a3e515616da102fc48a1e1af8a5b2f429f747e" a1a3e51]:
 {{{
 #!CommitTicketReference repository=""
 revision="a1a3e515616da102fc48a1e1af8a5b2f429f747e"
 Fixed #29133 -- Fixed call_command() crash if a required option is passed
 in options.
 }}}

-- 
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.785c9d679bc3d1853ddb273f4b83a15b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29176: User.normalize_username() crashes if username isn't a string

[Django]

#29176: User.normalize_username() crashes if username isn't a string
--+
 Reporter:  Christophe Mehay  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  2.0
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"40bac28faabbacd0875e59455cd80fb1dbb16966" 40bac28f]:
 {{{
 #!CommitTicketReference repository=""
 revision="40bac28faabbacd0875e59455cd80fb1dbb16966"
 Fixed #29176 -- Fixed AbstractBaseUser.normalize_username() crash if
 username isn't a string.
 }}}

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

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

Re: [Django] #29176: User.normalize_username() crashes if username isn't a string

[Django]

#29176: User.normalize_username() crashes if username isn't a string
--+
 Reporter:  Christophe Mehay  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  2.0
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"e91ff6e29cfd916afd3620adf4aeab733e06dbb5" e91ff6e]:
 {{{
 #!CommitTicketReference repository=""
 revision="e91ff6e29cfd916afd3620adf4aeab733e06dbb5"
 [2.0.x] Fixed #29176 -- Fixed AbstractBaseUser.normalize_username() crash
 if username isn't a string.

 Backport of 40bac28faabbacd0875e59455cd80fb1dbb16966 from master
 }}}

-- 
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.0f1ebbc518e331555d37d80fb668993d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29179: format_html() can falsely interpret a strack trace as a str.format replacement field

[Django]

#29179: format_html() can falsely interpret a strack trace as a str.format
replacement field
-+-
 Reporter:  Stephan Michaud  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  format_html, string  | 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):

 Oh, I see. Well, I'm not sure there's much Django can do about that. Did
 you consider escaping the traceback before passing it to `format_html()`?

-- 
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.0e01512144da8bcc1d3956edc0e84f3c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29180: makemigrations autodetector ignoring existing migrations (was: Makemigrations autodetector ignoring existing migrations)

[Django]

#29180: makemigrations autodetector ignoring existing migrations
-+
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted
 * type:  Uncategorized => 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/072.6b5f417039a714e1c2b18cd2491a299f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29179: format_html() can falsely interpret a strack trace as a str.format replacement field

[Django]

#29179: format_html() can falsely interpret a strack trace as a str.format
replacement field
-+-
 Reporter:  Stephan Michaud  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  format_html, string  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Stephan Michaud):

 Replying to [comment:2 Tim Graham]:
 > Could you give a minimal example that reproduces the issue (i.e. give
 the minimal string from the traceback and the arguments for
 `format_html()`)?

 Sure! Here's the string passed in to `format_html()`:
 {{{#!python
 showTraceback (most recent call last):
 File "/home/tool/www/project/common/utils.py", line 52, in inner
 ret = func(*args, **kwargs)
 File
 "/home/tool/www/project/servers/management/commands/servers_getindexation.py",
 line 31, in handle
 server.fetch_content()
 File "/home/tool/www/project/common/abstract_models.py", line 289, in
 fetch_content
 get=params[1],
 File "/home/tool/www/project/proxies/models.py", line 99, in
 append_process
 process.get_proxy_response()
 File "/home/tool/www/project/proxies/models.py", line 254, in
 get_proxy_response
 data = urllib.parse.urlencode({'request': self.get_serialized_data()})
 File "/home/tool/www/project/proxies/models.py", line 216, in
 get_serialized_data
 'useragent': self.request_useragent,
 File "/home/tool/venv/lib/python3.5/base64.py", line 59, in b64encode
 encoded = binascii.b2a_base64(s)[:-1]
 TypeError: a bytes-like object is required, not 'str'
 
 }}}

-- 
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.41f9605f68533fff786bf62bcae55e78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29178: Index.__init__()'s fields parameter shouldn't be mutable (was: Mutable default in `Index` constructor)

[Django]

#29178: Index.__init__()'s fields parameter shouldn't be mutable
-+-
 Reporter:  Flavio Curella   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 An older [https://github.com/django/django/pull/9368 PR] suggests
 accepting a list or tuple and defaulting to `fields=()`. Thoughts?

-- 
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.b9264debce1d4fff19b66896900e1c4d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29179: format_html() can falsely interpret a strack trace as a str.format replacement field (was: calling format_html can falsely interpret a strack trace as a str.format replacement fie

[Django]

#29179: format_html() can falsely interpret a strack trace as a str.format
replacement field
-+-
 Reporter:  Stephan Michaud  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  format_html, string  | 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 => Utilities


Comment:

 Could you give a minimal example that reproduces the issue (i.e. give the
 minimal string from the traceback and the arguments for `format_html()`)?

-- 
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.ba3be459afe8ae74aaad960242d22643%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29180: Makemigrations autodetector ignoring existing migrations

[Django]

#29180: Makemigrations autodetector ignoring existing migrations
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Collin Anderson):

 * cc: Collin Anderson (added)
 * needs_tests:  0 => 1


Comment:

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

-- 
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/072.ecf529849276cc109f30bdbd5288f785%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29180: Makemigrations autodetector ignoring existing migrations

[Django]

#29180: Makemigrations autodetector ignoring existing migrations
---+
   Reporter:  Collin Anderson  |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  Migrations   |Version:  master
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I don't have a minimal case to reproduce this issue, but I've bisected the
 issue to a38ae914 (#28996) and narrowed it down to this change:

 {{{
 diff --git a/django/db/migrations/graph.py b/django/db/migrations/graph.py
 index aba8259..db8a529 100644
 --- a/django/db/migrations/graph.py
 +++ b/django/db/migrations/graph.py
 @@ -367,9 +367,7 @@ class MigrationGraph:
  plan = []
  for node in nodes:
  for migration in self.forwards_plan(node):
 -if migration not in plan:
 -if not at_end and migration in nodes:
 -continue
 +if migration in plan or at_end or migration not in nodes:
  plan.append(migration)
  project_state = ProjectState(real_apps=real_apps)
  for node in plan:
 }}}

 I think believe the correct logic should be:

 {{{
 if migration not in plan and (at_end or migration not in nodes):
 plan.append(migration)
 }}}

-- 
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/057.1126d40dab95dcd0eaeb4d7ed0a4f385%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29166: in lookup doesn't work with lists in a When clause

[Django]

#29166: in lookup doesn't work with lists in a When clause
-+-
 Reporter:  Matthew Pava |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  lookup in| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Дилян Палаузов):

 * cc: Дилян Палаузов (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/064.14518ef80b93ea789e34499a05b84a9e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29166: in lookup doesn't work with lists in a When clause

[Django]

#29166: in lookup doesn't work with lists in a When clause
-+-
 Reporter:  Matthew Pava |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  lookup in| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Дилян Палаузов):

 {{{
 diff --git a/django/db/models/expressions.py
 b/django/db/models/expressions.py
 +return hash((path, output_field) + args + tuple([
 +(key, tuple(value)) if isinstance(value, list) else (key,
 value)
 +for key, value in kwargs.items()
 +]))
 }}}

 Aren't here the {{{[}}} and {{{]}}} superflous, as the parameter of both
 {{{tuple()}}} and {{{[]}}} have to be iterable, and this the type of the
 inlined {{{for}}}:
 {{{
 >>> tuple([(x,y) for x, y in {'a': 1, 'b':2, 'c':3}.items()])
 (('a', 1), ('b', 2), ('c', 3))
 >>> tuple((x,y) for x, y in {'a': 1, 'b':2, 'c':3}.items())
 (('a', 1), ('b', 2), ('c', 3))
 }}}

-- 
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.5b9e7207ba2b0de0c5df779b0e99103b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29179: calling format_html can falsely interpret a strack trace as a str.format replacement field

[Django]

#29179: calling format_html can falsely interpret a strack trace as a str.format
replacement field
-+-
 Reporter:  Stephan Michaud  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  format_html, string  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Stephan Michaud):

 * type:  Uncategorized => 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/066.e088240e798251b8db3aaa7d75ee8fae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29179: calling format_html can falsely interpret a strack trace as a str.format replacement field

[Django]

#29179: calling format_html can falsely interpret a strack trace as a str.format
replacement field
-+-
   Reporter:  Stephan|  Owner:  nobody
  Michaud|
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  1.10
  Uncategorized  |
   Severity:  Normal |   Keywords:  format_html, string
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi team,

 We have an internal page where we display stack traces on a web page.
 We've been using the `format_html` before rendering the data to the
 template, which has worked well in the past.
 However, one of the stack traces contained a dictionary definition as
 such:
 {{{#!python

 data = urllib.parse.urlencode({'request': self.get_serialized_data()})

 }}}
 Once that string reached the format_html function, it would cause the
 following Exception:
 {{{#!python
 KeyError: "'request'"
 }}}
 due to the call to `format()` recognizing the dictionary as a replacement
 field.

-- 
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/051.8c97f0bedf8a6713d287fe06a6370bcf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17664: {% if %} template tag silences exceptions inconsistently

[Django]

#17664: {% if %} template tag silences exceptions inconsistently
-+-
 Reporter:  Tai Lee  |Owner:  Robert
 |  Roskam
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:  Accepted
  queryset exception silenced|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Dufresne):

 > I think the choice to let boolean operations silence exceptions was a
 mistake. I think we should change this.

 I agree. Boolean conditions often hide private data. In the case of a
 programming mistake, I'd prefer an exception thrown so the programmer can
 fix it instead of plowing ahead with a potentially incorrect condition.
 Depending on the template, assuming a value could display private data to
 the wrong user.

 > So the intermediate step might be to raise a warning in the console for
 a minor version that exceptions will stopped being coerced to False soon.

 +1 This approach sounds sensible to me.

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

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

Re: [Django] #28715: Prevent a migration changing DateTimeField(auto_now_add=True) to default=timezone.now from generating SQL

[Django]

#28715: Prevent a migration changing DateTimeField(auto_now_add=True) to
default=timezone.now from generating SQL
--+
 Reporter:  Дилян Палаузов|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 Дилян Палаузов):

 * Attachment "auto_now_add_skip_sql_calls.patch" added.

 Probably somebody with more experience will tweak the
 
test.migrations.test_autodetector.test_add_date_fields_with_auto_now_add_(not_asking_for_null_addition,
 add_asking_for_default) tests, so that the line "kwargs['auto_now_add'] =
 True" in django/db/models/fields/__init__.py can be removed.  But
 otherwise this shall be ready to go.

-- 
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/072.7b63234cee3b711844401e8f19c1cedb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28715: Prevent a migration changing DateTimeField(auto_now_add=True) to default=timezone.now from generating SQL

[Django]

#28715: Prevent a migration changing DateTimeField(auto_now_add=True) to
default=timezone.now from generating SQL
--+
 Reporter:  Дилян Палаузов|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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 Дилян Палаузов):

 * Attachment "auto_now_add_skip_sql_calls.patch" added.

 Probably somebody with more experience will tweak the
 
test.migrations.test_autodetector.test_add_date_fields_with_auto_now_add_(not_asking_for_null_addition,
 add_asking_for_default) tests, so that the line "kwargs['auto_now_add'] =
 True" in django/db/models/fields/__init__.py can be removed.  But
 otherwise this shall be ready to go.

-- 
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/072.56e0d3ed77c7ed18adc2acf1464a6a62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29177: Unmanaged models with ForeignKeys do not get those fields serialized into their migration state when CreateModel happens.

[Django]

#29177: Unmanaged models with ForeignKeys do not get those fields serialized 
into
their migration state when CreateModel happens.
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  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 Keryn Knight):

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


Comment:

 WIP PR: https://github.com/django/django/pull/9741

-- 
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.4326a9b27905bd7c3ab4b73972a5ddf9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25367: Allow expressions in .filter() calls

[Django]

#25367: Allow expressions in .filter() calls
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Matthew
 Type:   |  Schinckel
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Matthew Schinckel):

 * owner:  nobody => Matthew Schinckel
 * status:  new => assigned


-- 
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.0bac8242b1e8d3189fdd6acafbb71393%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25367: Allow expressions in .filter() calls

[Django]

#25367: Allow expressions in .filter() calls
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Matthew Schinckel):

 Actually, I'm not sure it can - however, I'm not sure that we actually
 want to support that syntax - does it give anything over `Q(x='foo')`?

-- 
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.94195fefd7c7ecb074bc5b7dd7535399%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25367: Allow expressions in .filter() calls

[Django]

#25367: Allow expressions in .filter() calls
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Matthew Schinckel):

 The `.filter(F(x) == 'foo')` syntax doesn't work, and won't without quite
 a bit more work (basically, I think this would require the `__eq__` method
 on  `F` to return a non-boolean, which I think is probably Bad News(tm).)

 I think it can be spelled a different way using `ExpressionWrapper`.

-- 
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.e36da483e9c2a58570c8df0819138a22%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29173: Document that Model.save() doesn't refresh fields from the database

[Django]

#29173: Document that Model.save() doesn't refresh fields from the database
--+
 Reporter:  Xtreak|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
--+

Comment (by Xtreak):

 Replying to [comment:1 Tim Graham]:
 > I think that's expected behavior as it would add non-trivial overhead to
 refresh fields from the database after each `save()`. There might be a
 hook that would allow you to do that for your custom field.

 I think we don't need to refresh the value from db. Since we know during
 `get_prep_value` function call the value to be inserted in the database
 and we can update the object with the correct value which is inserted at
 
[https://github.com/django/django/blob/a2e97abd8149e78071806a52282a24c27fe8236b/django/db/models/sql/compiler.py#L1217].
 I might be wrong here due to my limited knowledge of ORM.

 However I also think it's a breaking change and it will be good to make a
 note of this behavior in the documentation than to make this code change.

 Thanks for all the work.

-- 
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.42c23f5313a917048d89e340526720a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.