Hi Thomas, On Wed, Feb 5, 2014 at 10:13 PM, Thomas Güttler <h...@tbz-pariv.de> wrote:
> Hi, > > here is some feedback to the check framework, documented at: > > https://docs.djangoproject.com/en/dev/ref/checks/ > > --- > > > {{{ > Error('error message', None) # Good > }}} > > I don't think this is "good". The "hint" should be optional. The above line > is ugly, since you don't know why there is second argument (None). > This was intended as a case of enforcing explicit > implicit. The next line in the documentation reads: {{{ Error('error message', hint=None) # Better }}} suggesting that the preferred syntax is to explicitly state that there isn't a hint. However, I can see how this might be slightly contrary to expectation for Python developers generally. I'd be interested in hearing other opinions on this. > --- > > https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-check > > {{{ > ... > > --tag <tagname> > > The system check framework performs many different types of checks. > }}} > > Which tags are available from django? > This is something I'm hoping to add to documentation in the near future. > How can I list the available tags (django tags and my tags)? > At present, there isn't any way. However, this is an interesting feature request - adding a --listtags option to `manage.py check` that just lists the tags that are available sounds like a good idea to me. > How can I list the available checks? > This is another area that where I'm hoping to improve documentation in the future. An automated --listchecks option would be a bit harder, because individual checks aren't registered anywhere centrally. > If a check needs two minutes, it is not wise to run it on "runserver" > on development machines. Is there a way to define which tests should > be included or excluded depending on the context. For example: if > "runserver" gets called don't call tests with have tag "foo". > I accept the problem in theory, but I'm having difficulty thinking of a situation where a check would take 2 minutes. My inclination is that this would be "solved by the market" - If Django (or a third party app) were to add a plugin that had extremely slow performance in real-world conditions, people would demand that it was removed or refactored. Do you have a specific idea for a check that might take a long time to run? > ---- > > https://docs.djangoproject.com/en/dev/ref/checks/# > registering-and-labeling-checks > > {{{ > @register('compatibility') > }}} > > I don't like strings like this, since it can contain typos. > > Are there objects for common tags? Example: > > {{{ > @register(Tag.COMPATIBILITY) > }}} > > Not at present; however, that sounds like a reasonable idea. > Thank you for this check framework. I like it. > > Thanks for the review notes! You've made a couple of really good suggestions here. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" 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/CAJxq84_k7-Pv-_JVQNEMpFhM0M%3Dgc_z%2BTDBwXxiMLphSyXV6KQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
