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 setting, as far as I'm aware that warning is completely silenced, and is not printed anywhere. If you think otherwise, you'll need to provide a specific example. > Let's assume that I am a guy who wants to silence every system check. We can assume that, but it doesn't provide an argument for anything unless you can make a reasonable case for _why_ you want to do that, and some evidence that other people also may want to do the same thing (these two are connected). So far I don't see either. > I > need to list ALL errors and warnings, which is: > * unhandy and it would require maintain a big list (especially after > upgrading Django to newer version) That's a good reason not to include this "feature." How can you say now that a check included in a future Django version won't be relevant to you or catch a bug in your code, when you don't even know yet what that check is? We don't add checks just for the fun of it -- we add them when we have good evidence that something is likely to be an error in many people's codebases. Such checks should be silenced when you understand the specific error and understand why it's not relevant in your unusual case. There's no way that you can make such an assertion about all possible future checks. > * messages are still visible (I don't need them and I don't want to > read them, and any other developer don't want to read them) I don't think this is true. > * django bootstraping is still slower due to executing system checks. This isn't relevant unless you have profiling data showing a noticeable difference in a realistic use case. > As an old-and-experienced-guy I want to disable (completely) system > checks on my responsibility. > Just belive me - I know what I'm doing. And I don't want to hack Django > to do any non-typical things. Why not? Isn't "I've hacked Django to do lots of non-typical things" the basis of your desire to disable system checks? So what's wrong with one more? > Why you can't add just one setting to bypass something which is > currently built-in? Is that a really big problem? Because every new setting is a new conditional path that has to be tested, and the interaction of every other feature with that new conditional path is now in theory a possible bug location. In other words, a single new boolean setting doubles the total number of possible configurations of Django that might contain a bug and need testing. All new code is a maintenance burden, and requires stronger justification than "one person said they wanted it." All that said, if we do this, it should be spelled `SILENCED_SYSTEM_CHECKS = ['*']`. I don't think there is ever a good case for using it, and I think users who don't understand how SILENCED_SYSTEM_CHECKS works may be tempted to use it to "just make the errors go away", but all in all I'm still only -0.5. 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/55CA1D46.10606%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
