Oh, sorry, I just saw that this is discussed (andanswered) in the PR. Am 13.01.20 um 23:03 schrieb Christian González: > > Eh, sorry if I misunderstand - but adding a "default = true" line to > an AppConfig is the same as addign default_app_config = > "foo.apps.FooConfig". > > A few things that came to my mind when reading the code: > > * You check if there is only one AppConfig available > (https://github.com/django/django/pull/12310/commits/6a4ee2d02477cac1fa67708ceefda2ffd56bbf96#diff-239ff7e40a4b9921b462471882a575f6R111) > and if so, this one is used - that's perfect IMHO. > > * But what if 2 AppConfigs have "default = true" ? Then line #139+ is > run, and silently the default app config class is used - none of the > two ones. Maybe an error message would be better. default=true should > only be valid once! > > Best regards, > > Christian > > Am 12.01.20 um 21:42 schrieb Aymeric Augustin: >> 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 >>> <mailto: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 >>> >>> -- >>> 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 >> <mailto: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 >> <https://groups.google.com/d/msgid/django-developers/A037EBE4-78A7-4037-9E8A-29DCC604CB85%40polytechnique.org?utm_medium=email&utm_source=footer>. > -- > Dr. Christian González > 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/f9dc1734-2148-bef7-95b1-d620f285d989%40nerdocs.at > <https://groups.google.com/d/msgid/django-developers/f9dc1734-2148-bef7-95b1-d620f285d989%40nerdocs.at?utm_medium=email&utm_source=footer>.
-- Dr. Christian González 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a9df802d-62c8-b0c9-7bf1-820284ad26e3%40nerdocs.at.
pEpkey.asc
Description: application/pgp-keys
