Re: [Django] #30688: Add example usage for Meta.base_manager_name

[Django]

#30688: Add example usage for Meta.base_manager_name
---+--
 Reporter:  agilgur5   |Owner:  agilgur5
 Type:  Uncategorized  |   Status:  assigned
Component:  Documentation  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by agilgur5):

 * owner:  nobody => agilgur5
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2a56760927a9869b62cd57c0202c53d5%40djangoproject.com.

[Django] #30688: Add example usage for Meta.base_manager_name

[Django]

#30688: Add example usage for Meta.base_manager_name
-+
   Reporter:  agilgur5   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  2.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 There is currently no documentation in topics or the reference about how
 ''specifically'' to use `Meta.base_manager_name` and I think an example
 could alleviate the confusion this causes.

 I had some trouble in a library I maintain (https://github.com/agilgur5
 /django-serializable-model/issues/4#issuecomment-519338032), where I
 mistakenly thought that `base_manager_name` should be set to,
 ''literally'' the name of the manager, as in the string equivalent to the
 name of the class of the manager (in my case, `'SerializableManager'`),
 similar to how one may reference models by string.
 Through finding some examples online like
 https://stackoverflow.com/a/48124863/3431180, I realized it's supposed to
 be the name of the attribute on the current class that contains the
 instance of the manager (in my case, `'objects'`).

 An example would really clear things up very concisely.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.263d6838a61d81c7921a1eada57599c0%40djangoproject.com.

Re: [Django] #30360: Support rotation of secret keys.

[Django]

#30360: Support rotation of secret keys.
---+-
 Reporter:  Andreas Pelme  |Owner:  Andreas Pelme
 Type:  New feature|   Status:  assigned
Component:  Core (Other)   |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by Ryan Hiebert):

 * cc: Ryan Hiebert (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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.b2b717839984ae65a7e376ca5204ca78%40djangoproject.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 Claude Paroz):

 To be clear, I'm also convinced parsing is more reliable than regexes. I
 just think we have to double-think before adding a dependency, because as
 the name implies, we depend on it and therefore we must be able to trust
 its maintainers. Some guarantees about the security process and serious
 bugs fixing should be obtained. Without that, we are just outsourcing
 problems.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.44f4794a79a91260cd88a2d06d34fbee%40djangoproject.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 Carlton Gibson):

 > AND it's just (even with the emphasis, cough) a wrapper around the
 underlying C library, so whilst 20 months seems a long time, I'm not sure
 the release cadence is really an issue.

 OK, that last one isn't at all true. (Looking at the source it's the
 entire implementation.)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.44993918c07dcd29cdd4b56b6101920f%40djangoproject.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 Carlton Gibson):

 Yep Claude, absolutely.

 I think there's two difficulties we could face:

 * trying to successfully sanitize HTML with regexes.
 * (Help) Make sure html5lib-python is maintained.

 The first of these is intractable. The second not. 

 I've put out some feelers to try and find out more.

 * This is pressing for Python and pip **now**, not for us for a while yet.
 * If we look at https://github.com/html5lib/html5lib-python/issues/361 it
 seems there's some money on the table from tidelift potentially.
 * We COULD allocate some time in a pinch I think.
 * AND it's **just** a wrapper around the underlying C library, so whilst
 20 months seems a long time, I'm not sure the release cadence is really an
 issue.

 BUT, yes, absolutely. Let's hammer this out properly before we commit. 
 I will open a mailing list thread when I know more.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.473885d8f73b399665516e6e426002f5%40djangoproject.com.

Re: [Django] #30687: GIS distance lookups fail within subqueries using OuterRef

[Django]

#30687: GIS distance lookups fail within subqueries using OuterRef
-+-
 Reporter:  Andrew Brown |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Andrew Brown):

 * has_patch:  0 => 1


Comment:

 PR submitted: https://github.com/django/django/pull/11634

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b29b2bf693f35e316a985f87055493a5%40djangoproject.com.

[Django] #30687: GIS distance lookups fail within subqueries using OuterRef

[Django]

#30687: GIS distance lookups fail within subqueries using OuterRef
-+-
   Reporter:  Andrew |  Owner:  nobody
  Brown  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I discovered this when trying to make a query of this form:

 {{{#!python
 from django.db import models
 from django.contrib.gis.db.models.fields import PointField, RasterField

 class ModelA(models.Model):
 pointA = PointField()

 class ModelB(models.Model):
 pointB = PointField()


 def query1():
 return ModelA.objects.annotate(
 has_value=Exists(ModelB.objects.filter(
 pointB__dwithin=(OuterRef("pointA"), 10)
 ))
 ).filter(has_value=True)
 }}}

 This fails with "ValueError: This queryset contains a reference to an
 outer query and may only be used in a subquery"

 I dug into things, and while I may not fully understand how queries are
 processed, I think I've identified the problem in
 `Query.resolve_lookup_value()`:

 {{{#!python
 def resolve_lookup_value(self, value, can_reuse, allow_joins, simple_col):
 if hasattr(value, 'resolve_expression'):
 kwargs = {'reuse': can_reuse, 'allow_joins': allow_joins}
 if isinstance(value, F):
 kwargs['simple_col'] = simple_col
 value = value.resolve_expression(self, **kwargs)
 elif isinstance(value, (list, tuple)):
 # The items of the iterable may be expressions and therefore need
 # to be resolved independently.
 for sub_value in value:
 if hasattr(sub_value, 'resolve_expression'):
 if isinstance(sub_value, F):
 sub_value.resolve_expression(
 self, reuse=can_reuse, allow_joins=allow_joins,
 simple_col=simple_col,
 )
 else:
 sub_value.resolve_expression(self, reuse=can_reuse,
 allow_joins=allow_joins)
 return value
 }}}

 This resolves the value passed in as the rhs of a filter. For single
 objects, it calls `resolve_expression()` and then returns the result. But
 for multiple objects in a list or tuple, it calls `resolve_expression()`
 on each but doesn't return the resolved objects. Rather it returns the
 original list.

 As a consequence, during the call to filter, the passed in `OuterRef`
 object doesn't get resolved to a `ResolvedOuterRef` object, since the
 `__dwithin` lookup takes a tuple of `(value, distance)`, triggering that
 second code path above. Later during the call to annotate, the `OuterRef`
 does resolve to a `ResolvedOuterRef` but when the query is compiled,
 `ResolvedOuterRef.as_sql()` is called which raises the error.

 I modified `resolve_lookup_value()` to return the list or tuple of
 resolved values, and wrote a test for the query above, which I will submit
 in a PR shortly.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.6521171f7af93695fe73c74dbb0b5fdd%40djangoproject.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 Thomas Hooper):

 Hi Carlton, that would be fun, but this is bigger than I have time for
 now. It looks like you all have it in hand.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.47ce7d2e2784e70d7d2822cfb4afc9f5%40djangoproject.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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 Claude Paroz):

 Do we want to make both html5lib and bleach required dependencies of
 Django?
 html5lib latest release is now 20 months ago, and when I read issues like
 https://github.com/html5lib/html5lib-python/issues/419 without any
 maintainer feedback, I'm a bit worried. What about the security report
 workflow for those libs? What if a security issue is discovered in html5
 lib and the maintainers are unresponsive? Sorry to sound a bit negative,
 but I think those questions must be asked.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d603d6b28da9782f448c72f0e8e723d7%40djangoproject.com.

Re: [Django] #30685: Optimize QuerySet.count() with distinct() (was: Optimize QuerySet.count() with distinct() or annotate().)

[Django]

#30685: Optimize QuerySet.count() with distinct()
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (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
-+-

Comment (by Simon Charette):

 The `annotation` part is tracked in #28477 so I'll rename this ticket to
 only mention `distinct`.

 I'm afraid we can't simply clear the values and ordering, else quite bit
 of code in `get_aggregate`
 
[https://github.com/django/django/blob/65e86948b80262574058a94ccaae3a9b59c3faea/django/db/models/sql/query.py#L440-L444
 would be rendundant].

 One case that these changes don't consider is the fact that
 `.values('foo').distinct()` could influence the `.count()`

 e.g.

 {{{#!sql
 SELECT COUNT(*) FROM (SELECT DISTINCT author_id FROM book)
 }}}

 Is not equivalent to

 {{{#!sql
 SELECT COUNT(*) FROM (SELECT DISTINCT book_id FROM book)
 }}}

 I suggest you open a PR with your changes so CI can report what exactly
 that breaks.

 I'm getting three failures locally on SQLite; one related to the
 aforementioned `.values().distinct()` issue, one related to
 `.datetimes().distinct()` and one related to `order_by` spawning a
 multiple valued relationship.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.16ca13761866a2e2e345ae9d240763e3%40djangoproject.com.

Re: [Django] #21604: Embed raw queries as subqueries when used with an __in filter

[Django]

#21604: Embed raw queries as subqueries when used with an __in filter
-+-
 Reporter:  alex@…   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 This should be as easy as implementing `RawQuery.as_sql` to return
 `(self.sql, self.params)` and setting `has_select_fields=True` as class
 attribute.

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

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I think this ticket should either be repurposed or closed as
 `FilteredRelation` does allow custom left outer joins.

 What comment:11 is missing at this point is a way to perform subquery
 pushdown and a way to JOIN subqueries.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.53f3712afb1ebb37ece0b47698b0c40c%40djangoproject.com.

Re: [Django] #29019: createsuperuser crashes if a ManyToManyField is in REQUIRED_FIELDS

[Django]

#29019: createsuperuser crashes if a ManyToManyField is in REQUIRED_FIELDS
--+--
 Reporter:  James Kirsop  |Owner:  Hasan Ramezani
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  user custom   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Hasan Ramezani):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.de3c2f078ae4c7a28ab0b181fa4daef8%40djangoproject.com.

Re: [Django] #30685: Optimize QuerySet.count() with distinct() or annotate(). (was: Suboptimal QuerySet.distinct().count())

[Django]

#30685: Optimize QuerySet.count() with distinct() or annotate().
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (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
-+-

Comment (by Adam Sołtysik):

 Actually, wouldn't it be as simple as adding these two lines after `obj =
 self.clone()` here:
 
https://github.com/django/django/blob/05964b2198e53a8d66e34d83d9123e3051720b28/django/db/models/sql/query.py#L505-L514

 {{{
 obj.set_values(['pk'])
 obj.clear_ordering(force_empty=True)
 }}}

 I tried it and it seems to be working (didn't run tests, though). But I
 think I don't understand the second part of Simon's advice.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fc232f04845e7f3415e1b9406554f178%40djangoproject.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser. (was: Truncator.chars splits HTML entities)

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  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
---+
Changes (by Carlton Gibson):

 * version:  2.2 => master
 * stage:  Unreviewed => Accepted


Old description:

> I'm using Truncator.chars to truncate wikis, and it sometimes truncates
> in the middle of  entities, resulting in 'some text '

New description:

 Original description:

 > I'm using Truncator.chars to truncate wikis, and it sometimes truncates
 in the middle of  entities, resulting in 'some text '

 This is a limitation of the regex based implementation (which has had
 security issues, and presents an intractable problem).

 Better to move to use a HTML parser, for Truncate, and strip_tags(), via
 html5lib and bleach.

--

Comment:

 Right, good news is this isn't a regression from
 7f65974f8219729c047fbbf8cd5cc9d80faefe77.

 * The new example case fails on v2.2.3 
 * The suggestion for the regex change is in the part not changed as part
 of 7f65974f8219729c047fbbf8cd5cc9d80faefe77. (Which is why the new case
 fails, I suppose :)

 I don't want to accept a tweaking of the regex here. Rather, we should
 move to using `html5lib` as Florian suggests.
 Possibly this would entail small changes in behaviour around edge cases,
 to be called out in release notes, but
 would be a big win overall.

 This has previously been discussed by the Security Team as the required
 way forward.
 I've updated the title/description and will Accept accordingly.

 I've attached an initial WIP patch by Florian of an `html5lib`
 implementation of the core `_truncate_html()` method.

 An implementation of `strip_tags()` using `bleach` would go something
 like:

 {{{
 bleach.clean(text, tags=[], strip=True, strip_comments=True)
 }}}



 Thomas, would taking on making changes like these be something you'd be
 willing/keen to do? If so, I'm very happy to input to assist in any way.
 :)

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

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

Re: [Django] #30686: Truncator.chars splits HTML entities

[Django]

#30686: Truncator.chars splits HTML entities
---+--
 Reporter:  Thomas Hooper  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  2.2
 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 Carlton Gibson):

 * Attachment "possible-html5lib-truncator-implementation.patch" added.

 Example implemetation of _truncate_html() using html5lib, by Florian
 Apolloner

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.778f58a4023603ab59cdc9abcb1c5995%40djangoproject.com.

Re: [Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (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
-+-

Comment (by Carlton Gibson):

 > Adding .values('pk') of course solves this as well.

 Yes… and for the same reason, right? 

 Fancy taking on a PR as per Simon’s suggestion? (We’re happy to advise…)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.65461b15b2cb2e6e255f3f8a3f4e2575%40djangoproject.com.

Re: [Django] #30685: Suboptimal QuerySet.distinct().count()

[Django]

#30685: Suboptimal QuerySet.distinct().count()
-+-
 Reporter:  Adam Sołtysik|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (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
-+-

Comment (by Adam Sołtysik):

 Thank you for accepting. I have added `.values('pk').order_by()` before my
 `.count()` queries, but I'll be glad to be able to get rid of it.

 Just to add a bit more information. The "problem" is not only with
 `.distinct()`, also any `.annotate()` makes `count()` produce a subquery
 with the redundant annotations inside. For example, a query like this
 results in SQL that is 4 times slower for my data than the bare count:

 {{{Model.objects.annotate(id2=F('id')).count()}}}
 {{{(0.057) SELECT COUNT(*) FROM (SELECT "table"."id" AS Col1, "table"."id"
 AS "id2" FROM "table" GROUP BY "table"."id") subquery;}}}

 Adding `.values('pk')` of course solves this as well.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.64f6f82f6b1522b1edbe9d926e66d160%40djangoproject.com.

Re: [Django] #30676: Add a --pdb option to the test runner

[Django]

#30676: Add a --pdb option to the test runner
-+-
 Reporter:  Andrew Godwin|Owner:  Andrew
 |  Godwin
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  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 Carlton Gibson ):

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


Comment:

 In [changeset:"052388aba47ba7166886fc741cac5ce3b22fea58" 052388ab]:
 {{{
 #!CommitTicketReference repository=""
 revision="052388aba47ba7166886fc741cac5ce3b22fea58"
 Fixed #30676 -- Added --pdb option to test runner.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.e41312047d1b971a4a3dbc8478dcf58f%40djangoproject.com.

Re: [Django] #30680: Remove security.W007 check.

[Django]

#30680: Remove security.W007 check.
-+-
 Reporter:  Adam (Chainz)|Owner:  Adnan
  Johnson|  Umer
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"c5075360c50b6e681fb3e7d58e6e93ae96662f49" c5075360]:
 {{{
 #!CommitTicketReference repository=""
 revision="c5075360c50b6e681fb3e7d58e6e93ae96662f49"
 Fixed #30680 -- Removed obsolete system check for
 SECURE_BROWSER_XSS_FILTER setting.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.e6f4de2a8352910d1226cc30b5838784%40djangoproject.com.