I’ll try to be reasonably brief, since this can easily turn into a lengthy diatribe:
ABCs are out because they were only introduced in Python 2.6, and the Django developers have a set roadmap for Python version support (2.3 support was only dropped in 1.2).
As for object-inheriting mixins, they would be less Pythonic in more ways than just reducing readability. Django uses a
ModelBase metaclass for
Model objects, which actually analyses the defined model properties on initialisation, and populates
Model._meta with the fields,
Meta options, and other properties. It makes sense to reuse that framework for both types of models. This also allows Django to prevent abstract model fields from being overriden by inheriting models.
There’s plenty more reasons I can think of, all of them minor in themself, but they add up to make the current implementation much more Pythonic. There’s nothing inherently wrong with using object-inheriting mixins though.
One of the reasons is because of the way fields are defined on a model.
Fields are specified declaratively, in a way that a normal class would treat as class attributes. Yet they need to become instance attributes for when the class is actually instantiated, so that each instance can have its own value for each field. This is managed via the metaclass. This wouldn’t work with a normal abstract base class.
- Pass JSON to JS using Django render
- Django admin many-to-many intermediary models using through= and filter_horizontal
- Error while accessing sqlite3 shell from django application
- Proper declaration of an empty Django PostgreSQL JSONField default value in migration file