Empty string and none are not the same or in any way redundant.
Linters belong in ci. Humans belong in code review.
I can actually explain to a human why my text field has a default of none.
> Avoid using null on string-based fields such as CharField and TextField. If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data;” the Django convention is to use the empty string, not NULL. One exception is when a CharField has both unique=True and blank=True set. In this situation, null=True is required to avoid unique constraint violations when saving multiple objects with blank values.
[0] https://docs.djangoproject.com/en/3.1/ref/models/fields/#nul...
From chatting to folks, most applications just YOLO this, and accept downtime on every such DB operation; you might not even notice that this is happening at first because you'd need to have a create _during_ your DB migration. It'll bite you sooner or later though. I'm sure for many apps a client-side retry is totally acceptable, assuming it's safe to do so.
because while Django Doctor suggests potential improvements, I acknowledge they're not guaranteed to be correct according to the context
The idea that empty string and none are equivalent is distasteful.
Nobody makes this argument for int fields right? "Just use 0"?
I hate having different conventions for different field types and losing a potentially meaningful distinction between empty string and 0.
The idea seems to be born out of truthy & falsey values. (A big source of gotchas and bugs in my experience)
I'd say it's the role of django forms to clean data into a normalized form. So converting null to empty string there might make sense.
Soon we will be adding a config file so you can mute the things that ar vexatious