I think that the compromise is a good idea, but on the long term it implies
the creation of a field in order to support a third party library.
While there are historical reasons it would be best to just let the third
party library solve this problem on its own.
On Wednesday, August 12, 2015 at
Aymeric raised a ticket [1] noting that the FlatPage.enable_comments field
appears in the admin by default, but isn't used anywhere which could be a
bit confusing. It seems that django-contrib-comments has a moderation
feature where you can specify a field on your model to control how comments
Hi Marcin,
On 08/11/2015 10:44 AM, Marcin Nowak wrote:
> They aren't really silenced, but skipped. I would like to silence them
> for real. They are skipped, but still printed out.
I'm not sure what you're referring to here. If you include a system
check warning code in the SILENCED_SYSTEM_CHECKS
Tim,
They aren't really silenced, but skipped. I would like to silence them for
real. They are skipped, but still printed out.
Let's assume that I am a guy who wants to silence every system check. I
need to list ALL errors and warnings, which is:
* unhandy and it would require maintain a big
Sorry to keep it alive, but what about the ability to pass an iterator to
the method_decorator? It would be sightly similar to this:
def _wrapper(self, *args, **kwargs):
def bound_func(*args2, **kwargs2):
return func.__get__(self, type(self))(*args2, **kwargs2)
I'm not super convinced that form.instance is widely better than
form.save(commit=False).
That's even more true if we're not sufficiently convinced by it that we'd
be deprecating the existing style.
It would:
* Promote making views making in-place changes on the instance -> doesn't
tend to be
