date:20180110

Re: [Django] #28885: Bottom parts of "Congratulations!" page cut off internationalized content

2018-01-10 Thread Django

#28885: Bottom parts of "Congratulations!" page cut off internationalized 
content
-+-
 Reporter:  Maciej Olko  |Owner:  Himanshu
 |  Chauhan
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, template,  | Triage Stage:  Accepted
  defaults   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Himanshu Chauhan):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/9570 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/065.0725149298f0c95190b6123e8ab6519d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29007: DecimalValidator crashes on NaN, SNan, Inf, and Infinity values

2018-01-10 Thread Django

#29007: DecimalValidator crashes on NaN, SNan, Inf, and Infinity values
---+
 Reporter:  Fabio Bonelli  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Core (Other)   |  Version:  2.0
 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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"f636f0bb86a5ff3a61401f5ec7ea5d3392edd30f" f636f0bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="f636f0bb86a5ff3a61401f5ec7ea5d3392edd30f"
 Fixed #29007 -- Fixed DecimalValidator crash on NaN, SNan, Inf, and
 Infinity values.
 }}}

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

Re: [Django] #29006: DecimalField.clean() crashes on sNaN values

2018-01-10 Thread Django

#29006: DecimalField.clean() crashes on sNaN values
+--
 Reporter:  Tim Graham  |Owner:  Tim Graham
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  2.0
 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:"c886f3dee33adc9f94332b4133a37960e985e273" c886f3de]:
 {{{
 #!CommitTicketReference repository=""
 revision="c886f3dee33adc9f94332b4133a37960e985e273"
 Fixed #29006 -- Fixed DecimalField.clean() crash on sNaN values.
 }}}

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

[Django] #29007: DecimalValidator crashes on NaN, SNan, Inf, and Infinity values

2018-01-10 Thread Django

#29007: DecimalValidator crashes on NaN, SNan, Inf, and Infinity values
-+
   Reporter:  Fabio Bonelli  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core (Other)   |Version:  2.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 `DecimalValidator` crashes if it receives a value like NaN, SNan, Inf, and
 Infinity.
 {{{
 >>> DecimalValidator(decimal_places=2, max_digits=10)(Decimal('NaN'))
 ...
   File "django/tests/validators/tests.py", line 322, in test_func
 validator(value)
   File "django/django/core/validators.py", line 417, in __call__
 if exponent >= 0:
 TypeError: unorderable types: str() >= int()
 }}}

 [https://github.com/django/django/pull/9082 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/049.3e7f2dff9cb71b1c4320966f0249495d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29006: DecimalField.clean() crashes on sNaN values

2018-01-10 Thread Django

#29006: DecimalField.clean() crashes on sNaN values
+--
 Reporter:  Tim Graham  |Owner:  Tim Graham
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/9567 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/067.3f23a631fd5355af90b3d5c7912002d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29006: DecimalField.clean() crashes on sNaN values

2018-01-10 Thread Django

#29006: DecimalField.clean() crashes on sNaN values
--+
   Reporter:  Tim Graham  |  Owner:  Tim Graham
   Type:  Bug | Status:  assigned
  Component:  Forms   |Version:  2.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 {{{
 >>> from django.forms import DecimalField
 >>> DecimalField(max_digits=4, decimal_places=2)
 >>> f.clean('sNan')
 
   File "django/django/forms/fields.py", line 148, in clean
 self.validate(value)
   File "django/django/forms/fields.py", line 354, in validate
 if not math.isfinite(value):
 ValueError: cannot convert signaling NaN to float
 }}}

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

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

Re: [Django] #28828: Performance improvements for HttpRequest.build_absolute_uri()

2018-01-10 Thread Django

#28828: Performance improvements for HttpRequest.build_absolute_uri()
-+-
 Reporter:  gcbirzan |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"5bf62825b591372739a082be7bfc9c59e54bbc1f" 5bf62825]:
 {{{
 #!CommitTicketReference repository=""
 revision="5bf62825b591372739a082be7bfc9c59e54bbc1f"
 Fixed #28828 -- Improved performance of HttpRequest.build_absolute_uri().
 }}}

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

Re: [Django] #28761: Document prefixes in InlineFormsets

2018-01-10 Thread Django

#28761: Document prefixes in InlineFormsets
-+-
 Reporter:  Jay Welborn  |Owner:  Jay
 Type:   |  Welborn
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  InlineFormsets   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Ready for checkin => Accepted


Comment:

 The latest version of the patch hasn't been reviewed yet.

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

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

Re: [Django] #28991: Add an admin filter with choices "all", "blank", "not blank" (was: Add new BlankFieldListFilter admin filter)

2018-01-10 Thread Django

#28991: Add an admin filter with choices "all", "blank", "not blank"
---+
 Reporter:  Jonas Haag |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

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

Re: [Django] #29004: Allow inspectdb to create models from database views

2018-01-10 Thread Django

#29004: Allow inspectdb to create models from database views
-+-
 Reporter:  Brendan Quinn|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM, db, database| Triage Stage:  Accepted
  views  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #28694: Make django.utils.text.slugify() remove redundant dashes and underscores

2018-01-10 Thread Django

#28694: Make django.utils.text.slugify() remove redundant dashes and underscores
-+-
 Reporter:  Elinaldo do  |Owner:  Elinaldo
  Nascimento Monteiro|  do Nascimento Monteiro
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  slugify, util| 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


Comment:

 The current version of the patch converts all underscores to dashes which
 (as discussed on the PR) isn't an obviously desired change. A discussion
 is needed to see if there's consensus about that change.

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

Re: [Django] #28973: Move the output of every file that collectstatic processes to verbosity level 2 (was: Change verbosity level of collectstatic command's outputs)

2018-01-10 Thread Django

#28973: Move the output of every file that collectstatic processes to verbosity
level 2
-+-
 Reporter:  Tanguy Nodet |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  collecstatic | Triage Stage:  Accepted
  verbosity log logging management   |
  command|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Tentatively accepting as per [https://groups.google.com/d/topic/django-
 developers/LAQyOQ1dMEA/discussion django-developers discussion].

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

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

Re: [Django] #28983: Documentation on providing initial data with migrations is unhelpful

2018-01-10 Thread Django

#28983: Documentation on providing initial data with migrations is unhelpful
-+-
 Reporter:  Rob Atkinson |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:
 |  worksforme
 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:   => worksforme


Comment:

 Please reopen if you have a patch to provide.

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

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

Re: [Django] #29000: RenameModel does not rename M2M column when run after AlterField/RenameField

2018-01-10 Thread Django

#29000: RenameModel does not rename M2M column when run after
AlterField/RenameField
-+
 Reporter:  David Nelson Adamec  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks, good bug report. I can also reproduce on PostgreSQL with Django
 master (e2908ecb3e20a629be801ddb826c474f7e7023ea).

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

Re: [Django] #28638: Make the allowed_hosts parameter mandatory for is_safe_url() (was: Allow `is_safe_url` to work without `allowed_hosts` or make the parameter mandatory)

2018-01-10 Thread Django

#28638: Make the allowed_hosts parameter mandatory for is_safe_url()
-+-
 Reporter:  kemar|Owner:  Piotr
 Type:   |  Domański
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  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:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Looks good, pending a few small changes.

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

Re: [Django] #28977: Change Local Memory Cache to Use LRU

2018-01-10 Thread Django

#28977: Change Local Memory Cache to Use LRU
-+-
 Reporter:  Grant Jenks  |Owner:  Grant
 |  Jenks
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  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 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/068.4aad1b869f932afdb1d9698d679b611c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28960: Implement GEOS.BufferWithStyle

2018-01-10 Thread Django

#28960: Implement GEOS.BufferWithStyle
-+-
 Reporter:  Stanislav Karpov |Owner:  Stanislav
 |  Karpov
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  gis, geodjango,  | Triage Stage:  Accepted
  geos   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Stanislav Karpov):

 Portable version for Django < 2.1:
 https://gist.github.com/stkrp/468610f7be70be2d01adccb79ecccd6e.

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

Re: [Django] #24525: AssertionError at `Query.change_aliases`

2018-01-10 Thread Django

#24525: AssertionError at `Query.change_aliases`
-+-
 Reporter:  coolRR   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 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):

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


Comment:

 As the fix for this ticket is released, please open a new ticket with
 complete details to reproduce. Ideally, you could also
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/#bisecting-a-regression bisect] to find the commit where the
 behavior changed.

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

Re: [Django] #28943: Avoid the need to call get_context_data() in TemplateView subclasses

2018-01-10 Thread Django

#28943: Avoid the need to call get_context_data() in TemplateView subclasses
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Generic views|  Version:  2.0
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Unless I missed something, `super().get()` will call the `TemplateView`
 implementation, even if you override `get()` in a subclass.

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

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

Re: [Django] #28977: Change Local Memory Cache to Use LRU

2018-01-10 Thread Django

#28977: Change Local Memory Cache to Use LRU
-+-
 Reporter:  Grant Jenks  |Owner:  Grant
 |  Jenks
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  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
-+-

Comment (by Grant Jenks):

 One more set of benchmarks. The above results benchmark in a single-
 process and single-thread environment. There's therefore never a time when
 the locks contend with one another for access. I thought it would be
 useful to observe performance with more contention and my development
 machine has eight logical processors so here's the results in a single-
 process and eight-thread environment.

 The current implementation:

 {{{
 = = = = = = =
 =
 Timings for locmem
 ---
Action Count  MissMedian   P90   P99   Max
 Total
 = = = = = = =
 =
   get712648 85412  14.067us 863.075us   2.461ms  14.337ms
 160.973s
   set 71226 0 204.563us 238.180us 282.288us   7.419ms
 12.356s
delete  8118 0 201.941us 235.081us 281.811us 410.080us
 1.395s
 Total791992
 174.724s
 = = = = = = =
 =
 }}}

 The new implementation:

 {{{
 = = = = = = =
 =
 Timings for locmem
 ---
Action Count  MissMedian   P90   P99   Max
 Total
 = = = = = = =
 =
   get712637 84222 146.151us 165.224us 201.225us   9.591ms
 106.855s
   set 71241 0 149.012us 167.847us 204.802us   9.604ms
 10.875s
delete  8114 0 144.958us 163.078us 195.026us 552.893us
 1.200s
 Total791992
 118.930s
 = = = = = = =
 =
 }}}

 The results overall display less variation but the median "get" time is
 10x slower (14 microseconds vs 146 microseconds). Despite that large
 slowdown, the total time for "get" operations is ~33% faster (160 seconds
 vs 106 seconds). The "set" and "delete" operations have comparable
 performance.

 The LRU eviction policy turns every read into a write which obsoletes the
 django.utils.synch.RWLock used in the current implementation. The RWLock
 was capable of giving multiple readers concurrent access but with the
 additional overhead. Therefore we see in the "no contention" scenario that
 the overhead is less by using threading.RLock. In the "high contention"
 scenario the additional overhead gives reads an advantage at the median
 but a larger penalty at the 99th percentile.

 I think these tradeoffs are easy to accept. Note that the benchmark does
 not include a miss-rate penalty which the LRU-eviction policy will almost
 certainly improve compared with the current random-eviction policy.

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

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

Re: [Django] #24525: AssertionError at `Query.change_aliases`

2018-01-10 Thread Django

#24525: AssertionError at `Query.change_aliases`
-+-
 Reporter:  coolRR   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   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 Christian Karrié):

 * version:  1.7 => 1.11


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

Re: [Django] #24525: AssertionError at `Query.change_aliases`

2018-01-10 Thread Django

#24525: AssertionError at `Query.change_aliases`
-+-
 Reporter:  coolRR   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   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 Christian Karrié):

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


Comment:

 Hi all, unfortunately I have to reopen this issue.

 After migrating from Django 1.10.6 to 1.11.9 the error reoccurs:

 Code:


 {{{
 qs_out = qs.filter(*out_filters)
 qs_in = qs.filter(*in_filters)
 qs_merged = qs_in | qs_out
 }}}

 Vars:

 `in_filters = [, , , ]`
 `out_filters = [, ]`

 It seems to fail, if `qs_in` or `qs_out` is empty. But I'm not sure.

 Printing `change_map` gives me:


 {{{
 {'T7': u'invoice_customer', u'invoice_customer': 'T7'}
 }}}

 Removing the assert works.

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

Re: [Django] #28943: Avoid the need to call get_context_data() in TemplateView subclasses

2018-01-10 Thread Django

#28943: Avoid the need to call get_context_data() in TemplateView subclasses
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Generic views|  Version:  2.0
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by James Pic):

 Of course, that works, unless you've overridden get() to do things that
 you don't want to happen on post.

 In post, i would like to render to template again, not run get() ;)

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

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

Re: [Django] #28977: Change Local Memory Cache to Use LRU

2018-01-10 Thread Django

#28977: Change Local Memory Cache to Use LRU
-+-
 Reporter:  Grant Jenks  |Owner:  Grant
 |  Jenks
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  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
-+-

Comment (by Grant Jenks):

 Josh asked on django-developers if I would run more extensive benchmarking
 against the current changes. Here's the results of the locmem backend
 using the python-diskcache benchmark harness. Note that these were
 generated with only one process as locmem does no cross-process
 synchronization.

 The current implementation benchmark results:

 {{{
 = = = = = = =
 =
 Timings for locmem
 ---
Action Count  MissMedian   P90   P99   Max
 Total
 = = = = = = =
 =
   get 88986 16526  12.159us  19.789us  28.849us 154.734us
 1.266s
   set  9030 0  14.067us  15.974us  30.994us 150.919us
 134.134ms
delete   983 0  11.921us  13.828us  26.941us  32.663us
 12.563ms
 Total 98999
 1.413s
 = = = = = = =
 =
 }}}

 And the new implementation benchmark results:

 {{{
 = = = = = = =
 =
 Timings for locmem
 ---
Action Count  MissMedian   P90   P99   Max
 Total
 = = = = = = =
 =
   get 88986 16526   5.007us   5.245us  14.067us  80.109us
 449.330ms
   set  9030 0   5.960us   7.153us  16.689us 111.103us
 58.852ms
delete   983 0   4.053us   5.007us   8.821us  18.835us
 4.200ms
 Total 98999
 512.381ms
 = = = = = = =
 =
 }}}

 Displayed is four percentiles of timing: Median (50th), 90th, 99th, and
 Max (100th). The results are better across the board with a 50% speedup
 typical.

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

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

Re: [Django] #28690: django.utils.http.parse_http_date two digit year check is incorrect

2018-01-10 Thread Django

#28690: django.utils.http.parse_http_date two digit year check is incorrect
-+-
 Reporter:  Mads Jensen  |Owner:  Alexander
 |  Vyushkov
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #28885: Bottom parts of "Congratulations!" page cut off internationalized content

2018-01-10 Thread Django

#28885: Bottom parts of "Congratulations!" page cut off internationalized 
content
-+-
 Reporter:  Maciej Olko  |Owner:  Himanshu
 |  Chauhan
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, template,  | Triage Stage:  Accepted
  defaults   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Himanshu Chauhan):

 * owner:  (none) => Himanshu Chauhan
 * 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/065.1310d71054897d9a24c7270e39aeac9c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28885: Bottom parts of "Congratulations!" page cut off internationalized content

2018-01-10 Thread Django

#28885: Bottom parts of "Congratulations!" page cut off internationalized 
content
-+-
 Reporter:  Maciej Olko  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, template,  | Triage Stage:  Accepted
  defaults   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Timothy Allen):

 * owner:  Timothy Allen => (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/065.5803c7a10c9ce4e7f152434f1b668c55%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28885: Bottom parts of "Congratulations!" page cut off internationalized content

2018-01-10 Thread Django

#28885: Bottom parts of "Congratulations!" page cut off internationalized 
content
-+-
 Reporter:  Maciej Olko  |Owner:  Timothy
 |  Allen
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, template,  | Triage Stage:  Accepted
  defaults   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by Timothy Allen):

 Replying to [comment:4 Himanshu Chauhan]:
 > I have tweaked the CSS of the web page so that it does not change
 original design and fix the mentioned bug. Can I claim this ticket and
 submit the patch?

 Absolutely! My colleague and I were working on a fix, but if you've got
 something complete, by all means take the ticket and issue a P.R. Thanks
 so much!

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

Re: [Django] #28638: Allow `is_safe_url` to work without `allowed_hosts` or make the parameter mandatory

2018-01-10 Thread Django

#28638: Allow `is_safe_url` to work without `allowed_hosts` or make the 
parameter
mandatory
-+-
 Reporter:  kemar|Owner:  Piotr
 Type:   |  Domański
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Dufresne):

 Depending on what gets decided, here is a
 [https://github.com/django/django/pull/9565 PR] to make `allowed_hosts`
 required.

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

Re: [Django] #28638: Allow `is_safe_url` to work without `allowed_hosts` or make the parameter mandatory

2018-01-10 Thread Django

#28638: Allow `is_safe_url` to work without `allowed_hosts` or make the 
parameter
mandatory
-+-
 Reporter:  kemar|Owner:  Piotr
 Type:   |  Domański
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I don't know that I would put much weight on that test case.
 `is_safe_url()` is undocumented, so backwards compatibility isn't a higher
 priority than making the change that makes the most sense. One of my
 thoughts is that things in `django.utils` shouldn't rely on Django
 settings, if possible. Like Jon, I lean toward making `allowed_hosts` a
 required argument.

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

Re: [Django] #28975: Skip automatic creation of postgis extension if it already exists

2018-01-10 Thread Django

#28975: Skip automatic creation of postgis extension if it already exists
-+-
 Reporter:  sphrak   |Owner:  sphrak
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  create extension,| Triage Stage:  Accepted
  postgis, psycopg2, postgresql  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by sphrak):

 This issue is currently stalled while waiting on response here:
 https://groups.google.com/forum/#!topic/django-developers/EjouxahkqUc


 Replying to [ticket:28975 sphrak]:
 > Hello,
 > I have found an issue with the documentation and/or the behaivor of the
 postgis extension create method.
 >
 > **Background**
 > I am trying to migrate my app that uses the postgis extension inside a
 docker container. I do create the extension beforehand as superuser since
 I dont intend to run the database connection as a postgres superuser.
 >
 > **Problem**
 > As per the documentation found here:
 https://docs.djangoproject.com/en/2.0/ref/contrib/gis/install/postgis/
 >
 >
 > I find it confusing that the documentation states "The command is run
 during the migrate process." and "An alternative is to use a migration
 operation in your project:". Because what seems to be the problem is that
 even if you remove the create extension statement from the migration file,
 it still runs regardless - rendering the option to put the create
 extension statement inside the migration file somewhat redundant and
 probably not very useful.
 >
 > **Possible solution**
 > Ideally the behaivor would be only create extension if its in a
 migration file and if its not - its the users concern to create it however
 it see fit.
 >
 > The relevant part is this:
 > {{{
 > testing.api |   File "/usr/lib/python3.6/site-
 packages/django/contrib/gis/db/backends/postgis/base.py", line 26, in
 prepare_database
 > testing.api | cursor.execute("CREATE EXTENSION IF NOT EXISTS
 postgis")
 > }}}
 >
 > Full trace:
 > {{{
 > testing.api | POSTGRES: I'm still down. Standby.
 > testing.api |   List of databases
 > testing.api |Name|  Owner   | Encoding | Collate |  Ctype  |
 Access privileges
 > testing.api |
 ---+--+--+-+-+---
 > testing.api |  postgres  | postgres | UTF8 | C   | C.UTF-8 |
 > testing.api |  template0 | postgres | UTF8 | C   | C.UTF-8 |
 =c/postgres  +
 > testing.api ||  |  | | |
 postgres=CTc/postgres
 > testing.api |  template1 | postgres | UTF8 | C   | C.UTF-8 |
 =c/postgres  +
 > testing.api ||  |  | | |
 postgres=CTc/postgres
 > testing.api |  testing   | postgres | UTF8 | C   | C.UTF-8 |
 =Tc/postgres +
 > testing.api ||  |  | | |
 postgres=CTc/postgres+
 > testing.api ||  |  | | |
 testing=CTc/postgres
 > testing.api | (4 rows)
 > testing.api |
 > testing.api | POSTGRES: I'm up, I'm up, I'm f* up - but I'm up
 > testing.api | Collecting selenium==3.3.1 (from -r
 /app/src/core/requirements/testing.txt (line 1))
 > testing.api |   Downloading selenium-3.3.1-py2.py3-none-any.whl (930kB)
 > testing.api | Collecting django-debug-toolbar==1.8 (from -r
 /app/src/core/requirements/testing.txt (line 2))
 > testing.api |   Downloading django_debug_toolbar-1.8-py2.py3-none-
 any.whl (205kB)
 > testing.api | Requirement already satisfied: Django>=1.8 in
 /usr/lib/python3.6/site-packages (from django-debug-toolbar==1.8->-r
 /app/src/core/requirements/testing.txt (line 2))
 > testing.api | Collecting sqlparse>=0.2.0 (from django-debug-
 toolbar==1.8->-r /app/src/core/requirements/testing.txt (line 2))
 > testing.api |   Downloading sqlparse-0.2.4-py2.py3-none-any.whl
 > testing.api | Requirement already satisfied: pytz in /usr/lib/python3.6
 /site-packages (from Django>=1.8->django-debug-toolbar==1.8->-r
 /app/src/core/requirements/testing.txt (line 2))
 > testing.api | Installing collected packages: selenium, sqlparse, django-
 debug-toolbar
 > testing.api | Successfully installed django-debug-toolbar-1.8
 selenium-3.3.1 sqlparse-0.2.4
 > testing.api | Traceback (most recent call last):
 > testing.api |   File "/usr/lib/python3.6/site-
 packages/django/db/backends/utils.py", line 83, in _execute
 > testing.

Re: [Django] #29001: postgres connection hstore support can disappear in low memory situations

2018-01-10 Thread Django

#29001: postgres connection hstore support can disappear in low memory 
situations
-+-
 Reporter:  Ronan Klyne  |Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.8
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  postgres hstore  | Triage Stage:
  signal weakref |  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:

 Sure, I think we should wait to fix a problem until we see it, so we can
 confirm the change is needed and that it fixes the issue. Thanks.

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

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

Re: [Django] #28638: Allow `is_safe_url` to work without `allowed_hosts` or make the parameter mandatory

2018-01-10 Thread Django

#28638: Allow `is_safe_url` to work without `allowed_hosts` or make the 
parameter
mandatory
-+-
 Reporter:  kemar|Owner:  Piotr
 Type:   |  Domański
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Dufresne):

 A test was added for `is_safe_url()` without a host argument in commit
 c5544d289233f501917e25970c03ed444abbd4f0. If the test case represents a
 use case, it looks like it could exist to verify URLs without a host
 component are safe.

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

Re: [Django] #28638: Allow `is_safe_url` to work without `allowed_hosts` or make the parameter mandatory

2018-01-10 Thread Django

Comment (by Jon Dufresne):

> I'm not sure if there's a use case for not providing it.

I'm also unsure what the use case if for using `is_safe_url` without an
`allowed_hosts` argument. To anyone that is asking for this feature, can
you provide details on your use case that would make it clear why this is
a good idea?

When I added `allowed_hosts` it was originally optional because, at the
time, the user could pass either `allowed_hosts` or `hosts`. Now that
there is only `allowed_hosts`, I think it should be a required argument
(unless a use case surfaces).

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

Re: [Django] #28885: Bottom parts of "Congratulations!" page cut off internationalized content

2018-01-10 Thread Django

#28885: Bottom parts of "Congratulations!" page cut off internationalized 
content
-+-
 Reporter:  Maciej Olko  |Owner:  Timothy
 |  Allen
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, template,  | Triage Stage:  Accepted
  defaults   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by Himanshu Chauhan):

 I have tweaked the CSS of the web page so that it does not change original
 design and fix the mentioned bug. Can I claim this ticket and submit the
 patch?

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

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

Re: [Django] #29001: postgres connection hstore support can disappear in low memory situations

2018-01-10 Thread Django

Comment (by Ronan Klyne):

I honestly don't know enough about the GC to explain this properly in the
docs but I have seen the problem happen in django-hstore. I was reading
the Django code and saw the same pattern so I pushed the same fix as a PR
here. At the very least it seemed like a more explicit description of the
desired effect - I don't think we would ever want this signal handler to
be garbage collected.

Django itself is using a module level function and django-hstore uses a
module level singleton callable class. That's close enough that I would
imagine that it's vulnerable to whatever peculiarity was breaking django-
hstore, though I can't explain why the garbage collector would collect it.

When this problem occurs it manifests as an hstore field being set to a
string value on the Model - the dictionary deserialisation is never
triggered.

Maybe you just want to archive this until that situation arises in the
wild?

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

Re: [Django] #28828: Performance improvements for HttpRequest.build_absolute_uri()

2018-01-10 Thread Django

#28828: Performance improvements for HttpRequest.build_absolute_uri()
-+-
 Reporter:  gcbirzan |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 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
-+-
Changes (by Keryn Knight):

 * stage:  Accepted => Ready for checkin


Comment:

 Anecdata verifying the improvement, using the following code against
 Python 3.5.1 on OSX:
 {{{
 from django.test.client import RequestFactory
 import timeit
 request = RequestFactory().get('/')
 timeit.timeit("request.build_absolute_uri(location='///foo/bar/')",
 number=100, globals={'request': request})
 request = RequestFactory().get('/')
 timeit.timeit("request.build_absolute_uri(location='/foo/./bar/')",
 number=100, globals={'request': request})
 }}}

 Master as of `d60e8b856b49922deb85a168e48e56f16facd5df` consistently
 yields **50.x-51.x seconds** for each timeit usage.
 PR yields **9 seconds** for the `///foo/bar/` case, and **33 seconds** for
 the less common `/foo/./bar/` case.

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

Re: [Django] #28638: Allow `is_safe_url` to work without `allowed_hosts` or make the parameter mandatory

2018-01-10 Thread Django

#28638: Allow `is_safe_url` to work without `allowed_hosts` or make the 
parameter
mandatory
-+-
 Reporter:  kemar|Owner:  Piotr
 Type:   |  Domański
  Cleanup/optimization   |   Status:  assigned
Component:  Utilities|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Keryn Knight):

 * cc: Keryn Knight (added)
 * needs_docs:  0 => 1


Comment:

 Assuming there's no objections to `default allowed_hosts to
 settings.ALLOWED_HOSTS but I am not sure if that is a good idea given that
 we can have star in there` the PR now looks OK to me, barring the need (I
 think) to add the change in behaviour to the release notes.

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

38 matches

Mail list logo