Sorry for my above answer I think the actual locks should go like this, so
all threads can actually go to the wait line while _populating is True.
def _populate(self):
self.lock.acquire()
if self._populating:
self.lock.wait()
self.lock.release()
return
Wouldn't a standard Lock do the trick? Also you are still vulnerable to a
race condition when reading self._populating, if the goal is to avoid
populating the object more than once in a short interval (in a case where
multiple requests hit the server before the object is initialized for the
fir
Has anyone relied on the exception silencing behavior as a "feature" when
using {% include %}? It doesn't seem that's really possible given you can't
use that feature when template.debug=True. Thus, the current behavior
doesn't strike me as a reasonable default. Perhaps we can change it after a
Thanks, I guess that can do it for now. It's a shame the one who started
implementing this in django itself just abandoned it :(
El lunes, 11 de julio de 2016, 8:55:17 (UTC-3), Alex Riina escribió:
>
> Here's an implementation:
>
> https://github.com/crccheck/django-object-actions
>
> Combining w
On Monday 11 July 2016 22:45:31 Florian Apolloner wrote:
> On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote:
> > As for me as a developer, I'd support removing the exception silencing
> > that {% include %} does so that errors appear alongside any other
> > exceptions (e.g. in Sentry)
Hey,
thanks for posting this here. I opened
https://code.djangoproject.com/ticket/26888 to keep track of this. Can I
get somebody with threading experience in Python tell me if your
proposed patch makes sense?
Also, I marked this as a release blocker for 1.10 as I introduced this
during a patch
On Monday, July 11, 2016 at 7:56:34 PM UTC+2, Tim Graham wrote:
>
> As for me as a developer, I'd support removing the exception silencing
> that {% include %} does so that errors appear alongside any other
> exceptions (e.g. in Sentry) rather than in the django.template logger (that
> logging
Found in another thread [0]: "Some time in late 2003, Adrian and I decided
that errors in templates were best handled silently - the idea was that it
would prevent untrained template editors from being able to 500-error a
site with a typo."
And another [1]: "The broad reasoning is that a parti
Hello everyone.
As suggested by Markus on django-users group, I'm posting this here too.
---
I'm using django (1, 10, 0, u'beta', 1).
When I try to reverse url in shell everything goes fine.
When under nginx/uwsgi with many concurrent request I get
... /local/lib/python2.7/site-packages/
s/card/csrf/
autocorrect grabbed that one from me.
On Monday, July 11, 2016 at 7:55:17 AM UTC-4, Alex Riina wrote:
>
> Here's an implementation:
>
> https://github.com/crccheck/django-object-actions
>
> Combining with other admin plugins that change the template requires
> overriding the templat
Here's an implementation:
https://github.com/crccheck/django-object-actions
Combining with other admin plugins that change the template requires overriding
the template to fit both changes in.
The actions are GETs and have no card protection.
--
You received this message because you are subsc
Hi,
I'm bringing this back to the table since I can't believe I'm the only one
to find this behaviour weird and possibly dangerous. I'd really be
interested in getting your opinion on this!
Thanks,
Sylvain
2016-06-09 14:37 GMT+02:00 Sylvain Fankhauser
:
> Hi all,
>
> I got really frustrated to
12 matches
Mail list logo