Warn when trying to use a widget as a field in a form

[Anders Hovmöller]

A common mistake beginners make is to import django.forms.Textarea and trying to use that as a Field, even though it's a widget. The result of doing this is just silence, so it's very difficult for the user to solve this problem by themselves.

We see this problem often in the Django Discord.

[Carlton Gibson]

Hi Anders. Thanks for this.

The sentiment here is right I think. More appropriate for a ​system check than a runtime warning however.

We don't currently have checks for Form &co. I'd like to canvas whether we can come up with enough to make an additional group of checks worthwhile.

There is a balance between being helpful and adding checks for every potential mis-use/mis-configuration that we're constantly trying to walk. Often we say that many checks better belong in user projects. (Adam Johnson has been writing lots of examples on his blog recently ​e.g.)

Initially I would create a project level base Form class, implementing the check, and registering that, plus maybe others. That can either just an example in a post, or a gist, or such, or else made into the PyPI package. Then I think canvasing for extra checks that could be considered in the category. It several come up then a third-party package becomes suitable. (Visibility plus shared burden of maintenance etc). Then we can look at whether adding that to core is a good idea, given benefit vs check speed and maintenance cost, which would go via the DevelopersMailingList (This sounds like a lot but it's just creating the example base class really.)

In this particular case I'm a little hesitant, as it's not an error that could be missed — my field just won't be there — vs a configuration error that might go unnoticed (for which I want a check...) — I wonder if we could find a way to package up a set of checks such that they're just registered on demand… (I might install them in DEBUG etc.) I haven't seen anything like that. 🤔

[Anders Hovmöller]

More appropriate for a ​system check than a runtime warning however.

How would that work? If someone defines a form inside a view function or a get_form() method, that can't really be checked from a system check right?

DEBUG

Doing this check in DEBUG mode only makes sense to me. Would you be willing to accept such a change to the PR?

There is a balance between being helpful and adding checks for every potential mis-use/mis-configuration that we're constantly trying to walk.

Well... might I then suggest removing the super slow model verification the runserver does by default then? :) I am thinking of writing a PR to at least move that to a different thread or something so it doesn't make development so slow.

Often we say that many checks better belong in user projects.

I disagree with that sentiment when it's a common use case that is mostly hit by beginners who are not competent enough yet to even write such checks.

Could we maybe have had this discussion before the ticket was closed btw? It seems strange to do it this way...

[Carlton Gibson]

The workflow is pretty standard for OSS project. Discussion happen on the DevelopersMailingList with the Issue tracker for concrete addressable items.
This is more or less the only way to keep it maintainable given the volume of ideas/suggestions/reports.
See the guide on ​Requesting features — it does try to guide you to the mailing list rather than the issue tracker.

I'm not convinced that a whole new category of checks for forms is worth the maintenance cost. It may be! But my suggestion was to prototype it, and then canvas opinion as to whether to push it forwards. It's not just "if I did this would you take the PR" — we need a consensus that yes, this is a new group of checks we want to bring into the framework.