In the real world the GitHub PR bot gives the dev the choice of committing the advice or not. I appreciate that does not reflect perfectly in the game :)

> I also don't see anything wrong with explicit default arguments.

Very much your and your team's choice. I for one see them as noise. Does it add value explicitly stating all the fields of Field? https://docs.djangoproject.com/en/3.1/ref/models/fields/#fie...

If you would not explicitly state all of the defaults why state a subset of them?

> I also don't see anything wrong with explicit default arguments.

I think explicit default arguments should be used when they're documenting some behavior that the reader might not know or remember, but that isn't the case here.

E.g. with python's enumerate built-in, it's useful to the reader to know that it starts at 0 or whatever. But with Django's models, adding (null=False, blank=False, editable=True) isn't telling the reader anything that they likely wouldn't already know or assume, it's just making the code more difficult to read.

I really hate how Django doesn’t care about the difference between null (the lack of a value) and the empty string (the presence of a specific value). But if you’re going to use HTML forms as a way of editing that data in a generic way, I don’t really see a better option. How would you present a form containing a text field that was null in such a way that it would be preserved after the user edits a different field and saves?