2👍
✅
The benefits are listed in bullet form here. You can see that not requiring models.py
is just one of stated benefits of the new approach.
- Applications can run code at startup, before Django does anything else, with the ready() method of their configuration.
- Application labels are assigned correctly to models even when they’re defined outside of models.py. You don’t have to set app_label explicitly any more.
- It is possible to omit models.py entirely if an application doesn’t have any models.
- Applications can be relabeled with the label attribute of application configurations, to work around label conflicts.
- The name of applications can be customized in the admin with the verbose_name of application configurations.
- The admin automatically calls autodiscover() when Django starts. You can consequently remove this line from your URLconf.
- Django imports all application configurations and models as soon as it starts, through a deterministic and straightforward process. This should make it easier to diagnose import issues such as import loops.
In addition, various bugs having to do with app loading were fixed under the rubric of app-loading refactor. For example, it used to be that some parts of the system looked at the INSTALLED_APPS
from front-to-back and others back-to-front. Now the order is consistent throughout the system.
As for models.py
, it doesn’t make sense to use that to mark applications when it’s not necessary to have models to be an application (for example, a reusable app can just have templates, say, or management commands). You used to have to include an empty models.py
file; now you can leave it out entirely.
Source:stackexchange.com