One assertion in the ModelSerializer just don't seem to make any real sense

[jubuehrer]

In the get_field_names method of the ModelSerializer class is an assertion that seems to not make much sense.
When the condition fields is not None is true, this method checks if some fields are defined in the serializer that are not included in the fields of its Meta-class. But it ignores inherited serializer fields which renders this whole assertion useless in my eyes. The condition also seems to be poorly implemented as well, because it ignores if a serializer field gets overloaded in the inheriting serializer.
This assertion also makes the serializers less flexible, when the fields get set on initialization of the serializer (because the permissions are dynamically build). This assertion forces in this case to also make the _declared_fields dynamically which is just an unnecessary step.

I am using inheritance in my serializers and stumbled over this assertion multiple times. I get the idea to prevent that a serializer field does not get serialized and may confuse the developer. But at least for me this assertion blocks me from making things more flexible.
I found a hacky way to stop this assertion by overloading the get_field_names and try-except super-calling the method and checking if the assertion error contains the string "was declared on serializer" in which case it returns self.Meta.fields.

I suggest to remove this assertion all together, because it has no downsides, it is literally ignored on inheritance and is holding back more flexibility.

In case, the assertion should stay for some reason that I don't know yet, it should at least get changed to check every declared field - inherited or not.

[Natgho]

It seems you’re right about the issue. At this point, it might be sufficient to change the rule from a strict violation to a warning and simply notify the developer.

Another alternative is to make the “get_field_names” model smarter so that it also checks this structure in cases like inheritance.

I’m leaning toward the first suggestion; throwing an error feels like it directly restricts the developer. Instead, by issuing a warning and leaving the final decision to the developer, this potential bottleneck could be resolved.

Note: Based on the joint decision reached, I can develop a solution to this problem.

@auvipy what do you think?