Hello, I created a PR for this: https://github.com/django/django/pull/12310
I'd love to get some feedback on the design before I polish the patch. Best regards, -- Aymeric. > On 10 Jan 2020, at 14:18, Christian González <christian.gonza...@nerdocs.at> > wrote: > > > > Am 08.01.20 um 22:39 schrieb Aymeric Augustin: >> The original intent was to make configuration explicit by having settings.py >> reference directly the target AppConfig class. >> >> - When you write MIDDLEWARE = ["polls"], do you expect Django to enable >> "polls.middleware.PollsMiddleware"? >> - When you write INSTALLED_APPS = ["polls"], do you expect Django to enable >> "polls.apps.PollsAppConfig"? >> >> Many readers of this mailing list will answer "no" and "yes" respectively. I >> think the answer to both should be "no", according to Django's design >> philosophy >> <https://docs.djangoproject.com/en/3.0/misc/design-philosophies/#explicit-is-better-than-implicit>. >> (If you're about to argue that an application can provide more than one >> middleware — I'm aware of this and I know you understood my point anyway.) > Yes, that's exactly what I wanted to state. >> [...] >> >> If we're reversing course, giving up on explicitness and going for magic, we >> could embrace that decision fully: import the "apps" submodule inside each >> application; if it exists and it defines exactly one AppConfig subclass, use >> that as the config for this app. Then app authors can stop littering their >> __init__.py files with default_app_config. > That would be perfect IMHO. One could consider restricting it to the > same-named subclass like the app itself, so the app "foo" would need to have > "FooConfig" as default. > > I'm aware that this violates the 2nd "Zen of Python" principle "Explicit is > better than implicit". and "Special cases aren't special enough to break the > rules." - but the next one says: "Although practicality beats purity." > > Yes, too much "magic" leads to a system where half of it uses magic, and the > other half not - so it's not predictable for the developer what a certain > line does. > > But exactly in this part I think that having a "sane default" - in the sense > of app loading using by using the app name only - is ok. > > I would bet that the vast majority of apps don't have two AppConfigs. > And to urge all devs to use the more elaborative AppConfig line in > INSTALLED_APPS, just to make such special cases (and THESE are the special > cases!) are possible, is wrong IMHO. > > Let it be easy - even the variable says INSTALLED_APPS, not > INSTALLED_CONFIGS. And let there be the possibility to declare other > AppConfigs on demand. > > Christian > > > > -- > Dr. Christian González > https://nerdocs.at <https://nerdocs.at/> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/b37e3655-4253-75a1-b750-6c81a0f6cf26%40nerdocs.at > > <https://groups.google.com/d/msgid/django-developers/b37e3655-4253-75a1-b750-6c81a0f6cf26%40nerdocs.at?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/A037EBE4-78A7-4037-9E8A-29DCC604CB85%40polytechnique.org.
