Re: [Django] #33096: AdminEmailHandler emails blocked by gmail antivirus

[Django]

#33096: AdminEmailHandler emails blocked by gmail antivirus
-+-
 Reporter:  Jan Schär|Owner:  Jan Schär
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  3.2
 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 Mariusz Felisiak):

 * needs_tests:  1 => 0
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6c3e7d007a60b5c8cc3e5ca5faba45d9%40djangoproject.com.

Re: [Django] #26142: Provide a way for model formsets to disallow new object creation

[Django]

#26142: Provide a way for model formsets to disallow new object creation
-+
 Reporter:  Tim Graham   |Owner:  Vlad
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  dev
 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 Jacob Walls):

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

Re: [Django] #32820: Fields’ errors should be programmatically associated with fields.

[Django]

#32820: Fields’ errors should be programmatically associated with fields.
-+-
 Reporter:  Thibaud Colas|Owner:  Kapil
 |  Bansal
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:  Accepted
  forms  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Kapil Bansal):

 If I am not wrong, we need to remove the errorlist and use aria_techniques
 instead?

-- 
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.4c110aca9c0b27e257b0a0774a99f281%40djangoproject.com.

Re: [Django] #32820: Fields’ errors should be programmatically associated with fields.

[Django]

#32820: Fields’ errors should be programmatically associated with fields.
-+-
 Reporter:  Thibaud Colas|Owner:  Kapil
 |  Bansal
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:  Accepted
  forms  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Kapil Bansal):

 * owner:  (none) => Kapil Bansal
 * 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/070.12ba0c431eec292d86c7e4d07f64b059%40djangoproject.com.

Re: [Django] #33098: Micro-optimisation for functional.keep_lazy for single argument uses.

[Django]

#33098: Micro-optimisation for functional.keep_lazy for single argument uses.
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Keryn Knight):

 PR is here: https://github.com/django/django/pull/14849
 Currently waiting to see if a new revised version works, because it's too
 hot here at the moment, and there's a couple of problems with the variant
 proposed upthread. Most notably, checking for `'func_first_param_name' in
 kwargs` like a fool, but also additionally handling funcs which themselves
 declare `*args` or `**kwargs`.

 Performance remains roughly the same for single argument functions, unless
 they're using the kwarg form, in which case it's something like:
 {{{
 In [3]: %timeit escape(text='d')
 1.89 µs ± 73.6 ns per loop (mean ± std. dev. of 7 runs, 100 loops
 each)
 }}}

 Ain't done any tests for it yet, because I shudder at the thought, knowing
 that they'll probably require using mock, and there's definitely little
 point doing them if the ticket doesn't have merit :)

-- 
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/067.cdae1f79d7beb8d1e59e20b071dbac3f%40djangoproject.com.

Re: [Django] #33097: Class based simple tag that takes context fails with simple_tag(). (was: Class based simple tag that takes context fails "must have a first argument of 'context''")

[Django]

#33097: Class based simple tag that takes context fails with simple_tag().
-+--
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Template system  |  Version:  3.2
 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
-+--

-- 
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.38470a4f54e8c2d8eb14c339dce72370%40djangoproject.com.

Re: [Django] #33097: Class based simple tag that takes context fails "must have a first argument of 'context''"

[Django]

#33097: Class based simple tag that takes context fails "must have a first 
argument
of 'context''"
-+--
 Reporter:  Michael  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Template system  |  Version:  3.2
 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 Mariusz Felisiak):

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


Comment:

 It's documented that `simple_tag()` accepts functions not methods.

-- 
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.5fe65ac4b3bbb20e04793dc650005a93%40djangoproject.com.

Re: [Django] #33095: Admin actions shown with zero results

[Django]

#33095: Admin actions shown with zero results
-+-
 Reporter:  Richard Laager   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Richard, thanks yes... — I'm think I'm with Mariusz here, but it was an
 intentional change so I'd like to see some consensus to change it if we
 were going to after all this time. An approach to the
 DevelopersMailingList (with a fuller proposal, to guide folks along) would
 be appropriate.

 I hope that makes sense. 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.3295695664f5338c2722e5e7644eab11%40djangoproject.com.

Re: [Django] #33096: AdminEmailHandler emails blocked by gmail antivirus

[Django]

#33096: AdminEmailHandler emails blocked by gmail antivirus
-+-
 Reporter:  Jan Schär|Owner:  Jan Schär
 Type:  Bug  |   Status:  assigned
Component:  Error reporting  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  (none) => Jan Schär
 * status:  new => assigned
 * needs_tests:  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a8480364955567d9e650256ee4d77841%40djangoproject.com.

[Django] #33098: Micro-optimisation for functional.keep_lazy for single argument uses.

[Django]

#33098: Micro-optimisation for functional.keep_lazy for single argument uses.
-+-
   Reporter:  Keryn  |  Owner:  Keryn Knight
  Knight |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Template   |Version:  dev
  system |
   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  |
-+-
 `keep_lazy` has an internal decorator function, `wrapper` which may get
 called a lot during template rendering, because it's ultimately used by
 `conditional_escape` which is in turn used by `render_value_into_context`.

 Rendering the standard admin change form for a user via
 `client.get(f"/auth/user/1/change/")` 100 times gives me the following
 cprofile output:
 {{{
11694527 function calls (11041473 primitive calls) in 8.609 seconds
Ordered by: internal time
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 30200/3000.3070.0006.7030.022 defaulttags.py:160(render)
  64340.2420.0000.2500.000 {built-in method io.open}
1746000.2180.0000.6820.000 base.py:849(_resolve_lookup)
1940000.2040.0001.1200.000 base.py:698(resolve)
 29200/5000.1750.0006.7200.013 loader_tags.py:168(render)
 303020.1620.0000.7350.000 base.py:654(__init__)
 342400.1610.0000.3550.000 base.py:779(__init__)
 15137/55090.1570.0001.5550.000 base.py:455(parse)
 916390.1440.0000.5420.000 functional.py:226(wrapper).
 # 1.6%?
 ...
 }}}
 with `wrapper` being the important line, and then:
 {{{
 In [1]: from django.utils.html import escape
 In [2]: %timeit escape('d')
 2.2 µs ± 51.3 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
 }}}

 This is because the current implementation is:
 {{{
 if any(isinstance(arg, Promise) for arg in itertools.chain(args,
 kwargs.values())):
 return lazy_func(*args, **kwargs)
 return func(*args, **kwargs)
 }}}
 that is, it's optimised for the general case of N arguments. But Django's
 internal usage of `keep_lazy` is nearly unanimously on functions with a
 single argument.

 It is possible to derive (at decorator time rather than call time) whether
 or not the function being wrapped needs to support multiple arguments, via
 `inspect.signature` and dispatch to a different wrapper, which offers
 somewhat better performance.

 A super naive implementation looks like:
 {{{
 @wraps(func)
 def keep_lazy_single_argument_wrapper(arg):
 if isinstance(arg, Promise):
 return lazy_func(arg)
 return func(arg)

 @wraps(func)
 def keep_lazy_multiple_argument_wrapper(*args, **kwargs):
 if any(isinstance(arg, Promise) for arg in itertools.chain(args,
 kwargs.values())):
 return lazy_func(*args, **kwargs)
 return func(*args, **kwargs)

 if len(inspect.signature(func).parameters) == 1:
 return keep_lazy_single_argument_wrapper
 else:
 return keep_lazy_multiple_argument_wrapper
 }}}
 which provides the best difference:
 {{{
 11327832 function calls (10674778 primitive calls) in 9.062 seconds
Ordered by: internal time
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 ...
 916390.0590.0000.3390.000
 functional.py:227(keep_lazy_single_argument_wrapper). # 0.6% of time
 }}}
 and the actual usage time:
 {{{
 In [2]: %timeit escape('d')
 1.5 µs ± 16.5 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
 }}}
 Though it comes at the cost of no longer being able to use keyword
 arguments:
 {{{
 In [3]: escape(text=1)
 TypeError: keep_lazy_single_argument_wrapper() got an unexpected keyword
 argument 'text'
 }}}
 which can be worked around by doing something (back of the napkin) like:
 {{{
 func_params = inspect.signature(func).parameters
 func_first_param_name = tuple(func_params.keys())[0]

 @wraps(func)
 def keep_lazy_single_argument_wrapper(*args, **kwargs):
 if (args and isinstance(args[0], Promise)) or ('func_first_param_name'
 in kwargs and isinstance(kwargs.get(func_first_param_name), Promise)):
 return lazy_func(*args, **kwargs)
 return func(*args, **kwargs)
 ...
 }}}
 which still seems to be better:
 {{{
11327896 function calls (10674842 primitive calls) in 9.411 seconds
Ordered by: internal time
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 ...
 916390.0880.0000.3820.000
 functional.py:230(keep_lazy_single_argument_wrapper). 

[Django] #33097: Class based simple tag that takes context fails "must have a first argument of 'context''"

[Django]

#33097: Class based simple tag that takes context fails "must have a first 
argument
of 'context''"
---+
   Reporter:  Michael  |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  Template system  |Version:  3.2
   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|
---+
 django.template.exceptions.TemplateSyntaxError: 'Foo' is decorated with
 takes_context=True so it must have a first argument of 'context'

 {{{
 class TextTag(Tag):
 """Return a template tag function for use as a text type tag.

 e.g. text text text
 Can override the 'render' method
 """
 def render(self, context, text, attrs):
 ...
 return html

 def as_template_tag(self, context, text, **attrs):
 tag = type(self)(self.tag, self.generic_css_class)
 return tag.render(context, text, attrs)
 }}}
 Used as
 {{{
 heading_section = TextTag('h3', 'HeadingSection').as_template_tag
 register.simple_tag(heading_section, name='HeadingSection',
 takes_context=True)
 }}}

 Raises exception:
 {{{
 django.template.exceptions.TemplateSyntaxError: 'HeadingFieldset' is
 decorated with takes_context=True so it must have a first argument of
 'context'
 }}}
 Should This error not be smart enough to see if its a methods, that once
 bound then context will be the first 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.53e40bea6b0b5c720bb3c331b36c678b%40djangoproject.com.

[Django] #33096: AdminEmailHandler emails blocked by gmail antivirus

[Django]

#33096: AdminEmailHandler emails blocked by gmail antivirus
---+
   Reporter:  Jan Schär|  Owner:  (none)
   Type:  Bug  | Status:  new
  Component:  Error reporting  |Version:  3.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|
---+
 Django errror/stack trace emails (django.utils.log.AdminEmailHandler) are
 blocked by the gmail antivirus with the following messages:

 {{{
 host gmail-smtp-in.l.google.com[142.250.110.26] said:
 This message was blocked because its content presents a potential
 security issue. Please visit
 https://support.google.com/mail/?p=BlockedMessage to review our
 message content and attachment content guidelines.
 }}}

 This is caused by the following tag in the html email:

 {{{
 https://dpaste.com/; name="pasteform" id="pasteform"
 method="post">
 }}}

 This worked before, so it is caused by a relatively recent change in
 gmail's antivirus.
 The fix is simply to remove the form tag, which should not have been there
 anyway.

 Patch: https://github.com/django/django/pull/14840

-- 
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.e6b8e357b16074c7bfbb7e9963893d40%40djangoproject.com.

Re: [Django] #33084: Removed incorrect fields.W343 check and notes about limit_choices_to restrictions for ManyToManyField.

[Django]

#33084: Removed incorrect fields.W343 check and notes about limit_choices_to
restrictions for ManyToManyField.
-+-
 Reporter:  jhbuhrman|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  limit_choices_to | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"0a28b42b1510b8093a90718bafd7627ed67fa13b" 0a28b42]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a28b42b1510b8093a90718bafd7627ed67fa13b"
 Fixed #33084 -- Removed incorrect system check for ManyToManyField with
 limit_choices_to.
 }}}

-- 
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/067.6b7f589e97325d9b0fa03c53e342e0ec%40djangoproject.com.

Re: [Django] #33091: A FieldError should be raised when trying to update MTI inherited field with F reference to child field

[Django]

#33091: A FieldError should be raised when trying to update MTI inherited field
with F reference to child field
-+-
 Reporter:  Shai Berger  |Owner:  Abhijith
 Type:   |  Ganesh
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 Abhijith Ganesh):

 * owner:  nobody => Abhijith Ganesh
 * status:  new => assigned


Comment:

 I am self assigning myself for this issue to avoid confusion.

-- 
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.1c8129df2d7530d1684d18671ea9e432%40djangoproject.com.

Re: [Django] #33091: A FieldError should be raised when trying to update MTI inherited field with F reference to child field

[Django]

#33091: A FieldError should be raised when trying to update MTI inherited field
with F reference to child field
-+-
 Reporter:  Shai Berger  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (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 Abhijith Ganesh):

 This is my first attempt of patching an actual django bug, now once i have
 made the patch and pushed it to my repository, I should be creating a PR.
 Is that all?

-- 
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.0cec047c94e9b0302a86fc15f41eff98%40djangoproject.com.

Re: [Django] #33092: Add note regarding thread-safety when using PyMemcacheCache.

[Django]

#33092: Add note regarding thread-safety when using PyMemcacheCache.
--+
 Reporter:  Martijn van der Blom  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  Version:  3.2
 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 Nick Pope):

 That's interesting - I'll have to have another try later.

 I don't know a great deal about this... Perhaps the issue is that
 `PooledClient` is using  `threading.Lock`. See
 
[https://github.com/pinterest/pymemcache/blob/b6d83f89fb93dfe7a006b470af487f113739cc56/pymemcache/pool.py#L32-L35
 here].

 As mentioned
 [https://github.com/gevent/gevent/issues/1381#issuecomment-478707377 here]
 some monkey patching needs to be done with `gevent.monkey.patch_all()`,
 but it seems that is
 
[https://github.com/benoitc/gunicorn/blob/f145e90e322256f1c4e1eea8e175d2e188ceab43/gunicorn/workers/ggevent.py#L38
 already handled] by gunicorn for the gevent worker.

 Perhaps you can try passing `lock_generator` in `OPTIONS` with a different
 lock type, e.g. see https://www.gevent.org/api/gevent.lock.html

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

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

Re: [Django] #33092: Add note regarding thread-safety when using PyMemcacheCache.

[Django]

#33092: Add note regarding thread-safety when using PyMemcacheCache.
--+
 Reporter:  Martijn van der Blom  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  Version:  3.2
 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 Martijn van der Blom):

 Thanks for the quick reply! I've tried your suggested solution, but
 although les frequent (3 vs 31 times), the error still occurs.
 I've verified that the config actually causes the HashClient to use a
 PooledClient and it does.
 I've updated the example in the git repo and attached a log to this issue.

 Do you guys have any clue as to what's happening here or any hints about
 what to do next?

-- 
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.3355676dbc559841d1bef7e232cefa9d%40djangoproject.com.

Re: [Django] #33073: AttributeError when annotating with Exists(none()) and aggregation

[Django]

#33073: AttributeError when annotating with Exists(none()) and aggregation
-+-
 Reporter:  Matthijs Kooijman|Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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
-+-

Comment (by Matthijs Kooijman):

 Thanks for the superquick fix. I can't quickly test it on my original
 problem (my project is still stuck on 2.x, really need to upgrade soon),
 but I'll try to remember to do so once I've upgraded :-)

-- 
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.3d1271371778a2847023aa615bae9f39%40djangoproject.com.

Re: [Django] #33092: Add note regarding thread-safety when using PyMemcacheCache.

[Django]

#33092: Add note regarding thread-safety when using PyMemcacheCache.
--+
 Reporter:  Martijn van der Blom  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  Version:  3.2
 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 Martijn van der Blom):

 * Attachment "use_pooling_true.log" added.

 Logfile of a run with use_pooling set to true

-- 
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.0cf53c0c7ec8157f1d9997751d6d82af%40djangoproject.com.

Re: [Django] #33084: Removed incorrect fields.W343 check and notes about limit_choices_to restrictions for ManyToManyField.

[Django]

#33084: Removed incorrect fields.W343 check and notes about limit_choices_to
restrictions for ManyToManyField.
-+-
 Reporter:  jhbuhrman|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  limit_choices_to | 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/067.3074a6ecad6f208feda8ab0dd328b525%40djangoproject.com.

Re: [Django] #33095: Admin actions shown with zero results

[Django]

#33095: Admin actions shown with zero results
-+-
 Reporter:  Richard Laager   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.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:  1
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:3 Richard Laager]:
 > And the same argument about the UI changing applies there too... it's
 going to change as soon as you add the first object.

 IMO, no, because you're adding new objects in a different view. So the
 layout is not changing when you're on it.

-- 
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.42ac1c8827deb8a4179dce3a65e6feb6%40djangoproject.com.

Re: [Django] #33094: "Show all" is ambiguous

[Django]

#33094: "Show all" is ambiguous
-+-
 Reporter:  Richard Laager   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Richard Laager):

 Fair enough. I didn't realize it cleared filters too.

 Part of my motivation here is that I'm upgrading from an old version of
 Django. It showed the pagination at the top of the page too, so there was
 a "Show all" link near the top of the page previously, and there is now,
 but they have different behaviors. I didn't expect this argument to carry
 much weight at this point, though, as people should be through this change
 already if they're staying on supported versions.

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

Re: [Django] #33094: "Show all" is ambiguous

[Django]

#33094: "Show all" is ambiguous
-+-
 Reporter:  Richard Laager   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  wontfix
 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 Richard Laager):

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

Re: [Django] #33095: Admin actions shown with zero results

[Django]

#33095: Admin actions shown with zero results
-+-
 Reporter:  Richard Laager   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.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:  1
-+-
Changes (by Richard Laager):

 * has_patch:  0 => 1


Comment:

 Replying to [comment:2 Mariusz Felisiak]:
 > Yes I believe that's intentional. It's true that you cannot do anything
 when there are no results on the page, however you can change filters
 dynamically and toggling actions every time would make it annoying.
 "wontfix" as for me, but I'm not a UX expert, so let's wait for the second
 opinion.

 Fair enough, but let me ask a couple follow-ups then... Is this important
 enough to justify a SELECT COUNT(*), which there are a bunch of complaints
 about in #8408? But more to the point, if this is going to show the
 actions if there are ''any rows in the table'', then why not just
 ''always'' show the actions? Surely it's not common to have a database
 table with 0 rows. And the same argument about the UI changing applies
 there too... it's going to change as soon as you add the first object.

-- 
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.eb472f5eff2bc1a3989c4f7ccaef0445%40djangoproject.com.