[Django] #29454: Default size for django.core.files.uploadedfile is None and then len will raise error

[Django]

#29454: Default size for django.core.files.uploadedfile is None and then len 
will
raise error
+
   Reporter:  jxltom|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  File uploads/storage  |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 |
+
 By default, ```size``` of  django.core.files.uploadedfile is ```None```
 and ```__len__``` will return ```size``` by default. Calling ```len```
 will raise ```TypeError: 'NoneType' object cannot be interpreted as an
 integer``` error if size is not assigned specifically.

 Can this be handled better? such as do not implement ```__len__``` method
 if ```size``` is set as ```None```

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

Re: [Django] #29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances during multilevel data prefetching

[Django]

#29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances
during multilevel data prefetching
-+-
 Reporter:  Alex Sichkar |Owner:  Paulo
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"25d4d8465b5a92cae5647117e2a42f71cd97a06f" 25d4d846]:
 {{{
 #!CommitTicketReference repository=""
 revision="25d4d8465b5a92cae5647117e2a42f71cd97a06f"
 [2.1.x] Fixed #29230 -- Fixed nested prefetches that clash with
 descriptors.

 Backport of 6104875a2cc797bbd1254aa61f22a9b03d652128 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.56320109eac190c61071edfb7048062a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances during multilevel data prefetching

[Django]

#29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances
during multilevel data prefetching
-+-
 Reporter:  Alex Sichkar |Owner:  Paulo
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prefetch_related | 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 ):

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


Comment:

 In [changeset:"6104875a2cc797bbd1254aa61f22a9b03d652128" 6104875a]:
 {{{
 #!CommitTicketReference repository=""
 revision="6104875a2cc797bbd1254aa61f22a9b03d652128"
 Fixed #29230 -- Fixed nested prefetches that clash with descriptors.
 }}}

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

Re: [Django] #29416: Undesired subquery added to the GROUP BY clause

[Django]

#29416: Undesired subquery added to the GROUP BY clause
-+-
 Reporter:  Antoine Pinsard  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  groupby, subquery| 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 ):

 In [changeset:"74bbef4ee0112144f302bb6509fd41a6b09ed63e" 74bbef4e]:
 {{{
 #!CommitTicketReference repository=""
 revision="74bbef4ee0112144f302bb6509fd41a6b09ed63e"
 [2.0.x] Fixed #29416 -- Removed unnecesary subquery from GROUP BY clause
 on MySQL when using a RawSQL annotation.

 Regression in 1d070d027c218285b66c0bde8079034b33a87f11.

 Backport of 4ab1f559e8d1264bcb20bb497988973194f5d8f2 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/066.0a12f6401d52a923f2c52dd07870df29%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29433: templatefilter "make_list" should receive a optional split variable

[Django]

#29433: templatefilter "make_list" should receive a optional split variable
-+-
 Reporter:  danilovmy|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  templatefilter,  | Triage Stage:  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Someday/Maybe


Comment:

 Write to the DevelopersMailingList to get a consensus about how to
 proceed.

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

Re: [Django] #29445: Compute defaults values with using of objects manager

[Django]

#29445: Compute defaults values with using of objects manager
-+-
 Reporter:  Yurii Shtrikker  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  compute, defaults,   | Triage Stage:
  fields, admin site, form   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Tim Graham):

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


Comment:

 The solution sounds rather specialized to me. I think the logic could be
 implemented in a custom form. You might try asking for help using the
 resources linked from TicketClosingReasons/UseSupportChannels.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.af46fc7f1bc29bdd4dc5e3cbe85c57c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29436: admin change_form.html in prepopulated_fields_js template tag always call second time every empty_form in inline_admin_formset

[Django]

#29436: admin change_form.html in prepopulated_fields_js template tag always 
call
second time every empty_form in inline_admin_formset
-+-
 Reporter:  danilovmy|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 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:   => needsinfo


Old description:

> admin change_form.html in prepopulated_fields_js template tag always call
> every empty_form in inline_admin_formset,
> thats take too much time, while every empty_form make __init__ the second
> time.
> The first time empty_form make __init__ for formset.render in template.

New description:

 admin change_form.html in prepopulated_fields_js template tag always call
 every empty_form in inline_admin_formset,
 thats take too much time, while every empty_form make `__init__` the
 second time.
 The first time empty_form make `__init__` for `formset.render` in
 template.

--

Comment:

 It's difficult for me to understand your report. Can you propose a patch?
 That would help clarify, I think.

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

Re: [Django] #29416: Undesired subquery added to the GROUP BY clause

[Django]

#29416: Undesired subquery added to the GROUP BY clause
-+-
 Reporter:  Antoine Pinsard  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  groupby, subquery| 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 ):

 In [changeset:"b6e48f514ebe4e31b76e1750e043d4f296e645dc" b6e48f51]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6e48f514ebe4e31b76e1750e043d4f296e645dc"
 [2.1.x] Fixed #29416 -- Removed unnecesary subquery from GROUP BY clause
 on MySQL when using a RawSQL annotation.

 Regression in 1d070d027c218285b66c0bde8079034b33a87f11.
 Backport of 4ab1f559e8d1264bcb20bb497988973194f5d8f2 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/066.509532e09172da43086f22e09932bf55%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29439: InlineAdminFormSet worked with forms array, but don't asks fieldset from every form in array

[Django]

#29439: InlineAdminFormSet worked with forms array, but don't asks fieldset from
every form in array
-+-
 Reporter:  danilovmy|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 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:   => needsinfo


Comment:

 Please include details to reproduce the problem. I can't tell what the
 problem is just based on the fix.

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

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

Re: [Django] #29434: model_to_dict should work with prefix

[Django]

#29434: model_to_dict should work with prefix
-+-
 Reporter:  danilovmy|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  models, prefix   | 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:   => needsinfo


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

Re: [Django] #29416: Undesired subquery added to the GROUP BY clause

[Django]

#29416: Undesired subquery added to the GROUP BY clause
-+-
 Reporter:  Antoine Pinsard  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  groupby, subquery| 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 Tim Graham ):

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


Comment:

 In [changeset:"4ab1f559e8d1264bcb20bb497988973194f5d8f2" 4ab1f559]:
 {{{
 #!CommitTicketReference repository=""
 revision="4ab1f559e8d1264bcb20bb497988973194f5d8f2"
 Fixed #29416 -- Removed unnecesary subquery from GROUP BY clause on MySQL
 when using a RawSQL annotation.

 Regression in 1d070d027c218285b66c0bde8079034b33a87f11.
 }}}

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

Re: [Django] #26819: Using a ArrayField on Meta.unique_together throws "unhashable type: 'list'" on validate_unique method

[Django]

#26819: Using a ArrayField on Meta.unique_together throws "unhashable type: 
'list'"
on validate_unique method
--+---
 Reporter:  Gleber Diniz  |Owner:  Demur Nodia
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  master
 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 Demur Nodia):

 Prepared fix for the issue during DjangoCon Europe 2018 sprints

 PR: https://github.com/django/django/pull/9993

 Used suggestions from previous work:

 * https://github.com/django/django/pull/7094#issuecomment-251481149
 * https://github.com/django/django/pull/7094#issuecomment-239900389

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

Re: [Django] #29417: Admin title still says "Change [model]" when user has view-only permission

[Django]

#29417: Admin title still says "Change [model]" when user has view-only 
permission
-+-
 Reporter:  Matthew Frazier  |Owner:  Ramiro
 |  Morales
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by Tim Graham ):

 In [changeset:"c56d94c02abbc10c71762f7ce9e352a67cb0d485" c56d94c]:
 {{{
 #!CommitTicketReference repository=""
 revision="c56d94c02abbc10c71762f7ce9e352a67cb0d485"
 [2.1.x] Fixed #29417 -- Corrected two admin page titles for view-only
 users.

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

Re: [Django] #29453: article_form.html not found

[Django]

#29453: article_form.html not found
---+--
 Reporter:  freeldev   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  2.0
 Severity:  Normal |   Resolution:  invalid
 Keywords:  article_form.html  | 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:   => invalid


Comment:

 See TicketClosingReasons/UseSupportChannels for ways to get help with
 Django usage.

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

[Django] #29453: article_form.html not found

[Django]

#29453: article_form.html not found
--+---
   Reporter:  freeldev|  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  2.0
   Severity:  Normal  |   Keywords:  article_form.html
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
 TemplateDoesNotExist at /articles/1/edit/

 articles/article_form.html

 Request Method: GET
 Request URL:http://127.0.0.1:8000/articles/1/edit/
 Django Version: 2.0.5
 Exception Type: TemplateDoesNotExist
 Exception Value:

 articles/article_form.html

 Exception Location: //.local/share/virtualenvs/newspaper-
 o5QhkDfx/lib/python3.6/site-packages/django/template/loader.py in
 select_template, line 47
 Python Executable:  //.local/share/virtualenvs/newspaper-
 o5QhkDfx/bin/python
 Python Version: 3.6.5
 Python Path:

 ['/tuts/django-for-beginners/newspaper',
  '//.local/share/virtualenvs/newspaper-o5QhkDfx/lib/python36.zip',
   '//.local/share/virtualenvs/newspaper-o5QhkDfx/lib/python3.6',
  '//.local/share/virtualenvs/newspaper-o5QhkDfx/lib/python3.6/lib-
 dynload',
  '/usr/lib/python3.6',
   '//.local/share/virtualenvs/newspaper-o5QhkDfx/lib/python3.6/site-
 packages']

 Server time:Sun, 27 May 2018 21:33:29 +0200


 Django tried loading these templates, in this order:

 Using engine django:

 django.template.loaders.filesystem.Loader:
 /newspaper/templates/articles/article_form.html (Source does not
 exist)
 django.template.loaders.app_directories.Loader:
 /.local/share/virtualenvs/newspaper-o5QhkDfx/lib/python3.6/site-
 packages/django/contrib/admin/templates/articles/article_form.html (Source
 does not exist)
 django.template.loaders.app_directories.Loader:
 /.local/share/virtualenvs/newspaper-o5QhkDfx/lib/python3.6/site-
 packages/django/contrib/auth/templates/articles/article_form.html (Source
 does not exist)
 django.template.loaders.app_directories.Loader:
 /.local/share/virtualenvs/newspaper-o5QhkDfx/lib/python3.6/site-
 packages/crispy_forms/templates/articles/article_form.html (Source does
 not exist)

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

Re: [Django] #29301: Reorder management command arguments in --help output to prioritize command-specific arguments

[Django]

#29301: Reorder management command arguments in --help output to prioritize
command-specific arguments
-+-
 Reporter:  David Foster |Owner:  David
 Type:   |  Foster
  Cleanup/optimization   |   Status:  new
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jann Haber):

 I have tested both PRs with django_nose and both don't make django-nose
 crash anymore. However, the outcome is a little different (as expected).

 The PR of Claude is missing to sort --verbosity to the end, however this
 could be added easily to the "show_last" list. The other arguments are
 sorted to the end as expected. The arguments are (other than the order of
 the arguments) identical as in Django 2.0

 The PR of David does not add the django --verbosity (-v) or --version,
 since these are "overwritten" by the corresponding arguments of nose.
 Please note, that it is already sufficient if e.g. only the short or only
 the long version of the argument is used by the third-party command, to
 have the ArgumentError appear and then to skip the entire argument. -v is
 already used by nose, so the django --verbosity is not added at all (the
 short version is also -v).

 I am also in favour of the PR of Claude. It seems to be the least impact
 option and achieves exactly what the PR was aiming for.

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

Re: [Django] #29359: Middleware documentation references ExceptionMiddleware, it is not anywhere in the code.

[Django]

#29359: Middleware documentation references ExceptionMiddleware, it is not 
anywhere
in the code.
--+
 Reporter:  Kevan Swanberg|Owner:  swang96
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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):

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


Comment:

 In a6fb5b1fe022c5279aa275c70b5193f2a2fac5fe:

 Removed docs for obsolete ExceptionMiddleware.

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

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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
-+-

Comment (by Bartosz Grabski):

 Will do.

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

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

Re: [Django] #23869: `get_deleted_objects` doesn't use `has_delete_permission`

[Django]

#23869: `get_deleted_objects` doesn't use `has_delete_permission`
---+-
 Reporter:  andreage   |Owner:  milkomeda
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  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 Steffen Jasper):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/9985 PR]

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

Re: [Django] #29301: Reorder management command arguments in --help output to prioritize command-specific arguments

[Django]

#29301: Reorder management command arguments in --help output to prioritize
command-specific arguments
-+-
 Reporter:  David Foster |Owner:  David
 Type:   |  Foster
  Cleanup/optimization   |   Status:  new
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (added)


Comment:

 Claude's custom formatter PR looks like the approach to me, since it is at
 the presentation layer only.

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

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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 Ingo Klöcker):

 * needs_better_patch:  0 => 1


Comment:

 I would add a test for this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.c1577f3ff4850f250b95061509acea9f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29444: Allow modification of RETURNING values in django.contrib.postgres

[Django]

#29444: Allow modification of RETURNING values in django.contrib.postgres
-+-
 Reporter:  Johannes Hoppe   |Owner:  Johannes
 |  Hoppe
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  django, db,  | Triage Stage:  Accepted
  returning, default, model, field   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Johannes Hoppe):

 * needs_better_patch:  0 => 1
 * 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.98d06a0008d837d49408df5889dbb096%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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 Bartosz Grabski):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/9997

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

Re: [Django] #28077: Allow specifying custom operator classes for PostgreSQL indexes

[Django]

#28077: Allow specifying custom operator classes for PostgreSQL indexes
-+-
 Reporter:  IzyJeepee|Owner:  Ian Foote
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, gin,   | Triage Stage:  Accepted
  operator, class|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ian Foote):

 I've noticed that in the
 
[https://github.com/django/django/blob/master/django/contrib/gis/db/backends/postgis/schema.py#L23-L41
 postgis schema editor], we have custom index creation code for single-
 field indexes for {{{geodetic}}} fields. For example, we set the
 {{{GIST_GEOMETRY_OPS_ND}}} operator class for fields with dimension higher
 than two.

 It would probably be good to refactor to allow this custom code to
 integrate with the operator class support I've added, but I'm not familiar
 enough with postgis to be confident making a change without guidance.

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

Re: [Django] #28892: Fixed header height in the admin site may break custom layouts

[Django]

#28892: Fixed header height in the admin site may break custom layouts
---+--
 Reporter:  Claude Paroz   |Owner:  Sara Heins
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  css| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Sara Heins):

 * has_patch:  0 => 1


Comment:

 Pull request submitted: https://github.com/django/django/pull/9996

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

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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 Markus Holtermann):

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

Re: [Django] #29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances during multilevel data prefetching

[Django]

#29230: Incorrect behavior of QuerySet.prefetch_related() in some circumstances
during multilevel data prefetching
-+-
 Reporter:  Alex Sichkar |Owner:  Paulo
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paulo):

 PR: https://github.com/django/django/pull/9995

 The commit in
 
https://code.djangoproject.com/changeset/379caf397ea41923278821085204c296f960e70e/
 didn't fix this.
 It just reversed the execution order of prefetch objects.

 Changing the attached test from:


 {{{
 projects = Project.objects.prefetch_related(
 Prefetch('tasks', queryset=tasks),
 Prefetch('tasks', to_attr='some_attr_name'),
 )
 }}}


 to:


 {{{
 projects = Project.objects.prefetch_related(
 Prefetch('tasks', to_attr='some_attr_name'),
 Prefetch('tasks', queryset=tasks),
 )
 }}}


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

Re: [Django] #28905: Overhaul extra_requires to include more optional dependencies

[Django]

#28905: Overhaul extra_requires to include more optional dependencies
-+-
 Reporter:  Jaap Roes|Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  setup optional   | Triage Stage:  Accepted
  dependencies packages  |
  requirements   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Israel Fermín Montilla):

 Can I claim it?, I have some spare time I could invest on this

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.db44d1213f2da58854f7b6a3ed93bcdb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Uncategorized|   Status:  assigned
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
-+-
Changes (by Bartosz Grabski):

 * owner:  nobody => Bartosz Grabski
 * 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/072.2eff94c14e828db8683ee172d11f0b7b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
+
   Reporter:  Bartosz Grabski   |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Internationalization  |Version:  1.11
   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 |
+
 When running `python manage.py makemessages`, I'm getting the following
 error:

 {{{
 CommandError: errors happened while running msguniq
 C:\dev\xxx\locale\django.pot:2738: C:\dev\xxx\locale\django.pot: input is
 not valid in "ASCII" encoding
 }}}

 This is because some of my translatable strings contain non-ASCII
 characters. I've checked the code in `makemessages.py` and found the
 culprit:

 {{{
 for line in pot_lines:
 if not found and not header_read:
 found = True
 line = line.replace('charset=CHARSET', 'charset=UTF-8')
 if not line and not found:
 header_read = True
 lines.append(line)
 }}}

 Since `found` is set to `True` on the first iteration, charset is never
 updated as it's usually on line 17.

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

Re: [Django] #29451: Add compatibility with MySQL 8

[Django]

#29451: Add compatibility with MySQL 8
-+-
 Reporter:  Tim Graham   |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:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (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/067.ef1cb8a62027552a8fcada2bb152dda5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28539: REMOTE_USER auth docs (and middleware logging?) should mention that headers with underscores are stripped when using "runserver" command

[Django]

#28539: REMOTE_USER auth docs (and middleware logging?) should mention that 
headers
with underscores are stripped when using "runserver" command
-+-
 Reporter:  jcmcken  |Owner:  Israel
 |  Fermín Montilla
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Israel Fermín Montilla):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #28539: REMOTE_USER auth docs (and middleware logging?) should mention that headers with underscores are stripped when using "runserver" command

[Django]

#28539: REMOTE_USER auth docs (and middleware logging?) should mention that 
headers
with underscores are stripped when using "runserver" command
-+-
 Reporter:  jcmcken  |Owner:  Israel
 |  Fermín Montilla
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Israel Fermín Montilla):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.699aa500c97324643c575b5d25679528%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29433: templatefilter "make_list" should receive a optional split variable

[Django]

#29433: templatefilter "make_list" should receive a optional split variable
-+--
 Reporter:  danilovmy|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  templatefilter,  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--

Comment (by Ingo Klöcker):

 I also think that adding a {{{split}}} filter (there's already a
 {{{join}}} filter) is useful. Sometimes we store lists of strings in
 simple CharFields and for display we need to replace the separator with a
 more human-friendly separator.

 So, who's going to decide if it shall be 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/067.824f453e32b0589d6526c981b9972c3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29425: Auto language redirect does not work if prefix_default_language=False in root URLConf

[Django]

#29425: Auto language redirect does not work if prefix_default_language=False in
root URLConf
-+-
 Reporter:  Nathan Humphreys |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 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 Ingo Klöcker):

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


Comment:

 I think there is a misunderstanding about what {{{i18n_patterns()}}} does.

 I have added the following to my root URL conf
 {{{
 urlpatterns += i18n_patterns(
 url(r'^about/$', about, name='about')
 )
 }}}
 and set {{{LANGUAGE_CODE}}} to {{{'en'}}} in {{{settings.py}}}.

 When I try
 {{{
 curl -vs http://127.0.0.1:8000/en/about/ >/dev/null
 }}}
 then I get
 {{{
 [...]
 < HTTP/1.0 200 OK
 [...]
 }}}

 But, when I try
 {{{
 curl -vs http://127.0.0.1:8000/about/ >/dev/null
 }}}
 then I get
 {{{
 [...]
 < HTTP/1.0 404 Not Found
 [...]
 }}}
 As you can see, no redirect happens.

 If I understand your report correctly, then you seem to have expected that
 the URL missing the language prefix (i.e.
 {{{http://127.0.0.1:8000/about/}}}) would have been auto-redirected to the
 prefixed URL (i.e. {{{http://127.0.0.1:8000/en/about/}}}). But that's not
 what {{{i18n_patterns()}}} does.

 All that {{{i18n_patterns()}}} does, is that it makes sure that URLs
 prefixed with the language prefix matching the user's Accept-Language
 header open the corresponding view. I have checked the code (there's
 nothing there that redirects) and the documentation (only one section,
 "The set_language redirect view", mentions redirects).

 If I have misunderstood your problem, then please reopen this report
 explaining your problem in more detail, e.g. by providing a small example
 project demonstrating the problem. Also provide some URLs demonstrating
 your expectations and what actually happens.

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

Re: [Django] #29441: Allow dumpdata in YAML using ruamel.yaml rather than PyYaml.

[Django]

#29441: Allow dumpdata in YAML using ruamel.yaml rather than PyYaml.
-+-
 Reporter:  Rémy Hubscher|Owner:  Daniel
 Type:   |  Rios
  Cleanup/optimization   |   Status:  closed
Component:  Core |  Version:  2.0
  (Serialization)|
 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 Daniel Rios):

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


Comment:

 Hi.
 First, reasons should be provided as to why something is recommended. In
 this case, ruaml is recommended because it is, as far as my research has
 taken me, the only other python yaml library out there.

 The preference for the pyyaml module is baked into
 `django/core/serializers/__init__.py` in the `BUILTIN_SERIALIZERS`
 constant at
 
https://github.com/django/django/blob/5cc81cd9eb69f5f7a711412c02039b435c393135/django/core/serializers/__init__.py#L26

 I don't think it makes sense to have another built-in serializer. However,
 there is a workaround:

 Django does offer the possibility to use your own serializer in the
 docstring of the same file
 
(https://github.com/django/django/blob/5cc81cd9eb69f5f7a711412c02039b435c393135/django/core/serializers/__init__.py#L10),
 but the actual user-facing documentation seems to be nonexistent.

 I was able to, however, overwrite the preference for pyyaml by installing
 ruamel and with `SERIALIZATION_MODULES` in settings.py as follows:
 {{{
 SERIALIZATION_MODULES = {
 'yaml': 'ruamel.yaml.serializer'
 }
 }}}

 I was unable to get it running because ruaml (even though based on pyyaml)
 is written a bit different to the way Django handles serializers but the
 fact that it does support other serializers means that it would be
 possible to get ruaml to work.

 A better idea would be to create a third party package `django-ruaml-
 serializer` that patches the differences in ruaml to work with the
 existing django serializer.

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