Re: Possible Bug in RegexURLResolver

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

Re: Possible Bug in RegexURLResolver

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

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

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

Re: Admin-Actions also in the object details view

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

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

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

Re: Possible Bug in RegexURLResolver

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

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

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 >

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

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

Possible Bug in RegexURLResolver

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 ...

Re: Admin-Actions also in the object details view

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

Re: Admin-Actions also in the object details view

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

Re: Exceptions caught by the "include" template tag make it hard to rely on tests

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,