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.
> 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.
Yes, I first read those as (null=True, blank=True) because I've never written out those arguments when their default is False. So for me writing them out explicitly with their defaults is an anti-pattern.
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?
You should probably check the data coming from the form and what's in the database. If the form sends an empty string for a null field in the database, you keep the null. If it sends an empty string for a not null field, you set an empty string in the db field. This assumes that the semantic of null is "never touched before".
You use hidden fields in the html form to preserve previous values and then compare them in your input validation code server side. You set the default value of input type text and text area to the previous value. If the value was blank before and after you save as null, otherwise you set it to the new value.
> 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?