At the risk of re-opening this thread, I have just run into a very similar situation (see https://code.djangoproject.com/ticket/25374) and find that having the errors printed to the console is actually helpful - as I've had to silence errors to get the correct code to run, seeing if there's any *other* errors being "accidentally" silenced is helpful.
It seems there's actually two behaviours being conflated in "SILENCE_SYSTEM_CHECKS": * Ignoring the error, so that the code will run (ie downgrade errors to warnings) * Not printing the message It's useful to be able to do the two things separately - I may want to downgrade an error because it's not one in my codebase, but still see if new instances of it creep in. Or I might want to not see any of a particular warning printed to the console. Could we split this to: IGNORED_SYSTEM_CHECKS and SILENCED_SYSTEM_CHECKS Malcolm On Thursday, 27 August 2015 14:09:06 UTC+1, Tim Graham wrote: > > I created a ticket and pull request for the silencing of error/critical > messages: > https://code.djangoproject.com/ticket/25318#ticket > https://github.com/django/django/pull/5197 > > On Tuesday, August 25, 2015 at 11:03:18 AM UTC-4, Carl Meyer wrote: >> >> On 08/25/2015 08:57 AM, Marcin Nowak wrote: >> > Well, I'm not sure now, because Tim wrote that it was a design decision >> > and it is well documented. >> >> I still think we should change that design. It is simply wrong to have a >> setting called `SILENCED_SYSTEM_CHECKS` that fails to actually _silence_ >> the check IDs listed. >> >> > Also please note that silencing specific errors is not the best >> solution. >> > In the first case E116 may be untrue and may be silenced, but for other >> > models this error may be true and shouldn't be silenced at all. >> > Silencing all E116 will give us messy information about state. >> >> That's why I think in this case the best solution is to actually fix the >> error, not silence it; Django should be able to find a find a field even >> if it's monkeypatched-in, as long as the monkeypatch happens in time. >> >> Carl >> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dc4e410c-708f-472b-bde2-49a45ad4e39d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
