I've read source code for django.conf package and as of Django 1.3
INSTALLED_APPS can accept wildcards for application names (e.g.
django.contrib.*). It seems that the official documentation doesn't
mention it in the Available Settings section.
Am I wrong?
I checked the SVN history. This "feature" was never documented, even before the reorganization at r8506. It appears in django/conf/__init__.py when magic-removal is merged (r2809).
We just discussed it on IRC, and the consensus is that it dates back to before Django was open-sourced. It was probably only used at World Online.
In my opinion, it's an anti-feature:
1 - It's un-pythonic: in essence, it's equivalent to an filesystem-based implementation of "from <package> import *", which was not rejected in Python for a good reason [1]
2 - like "from <module> import *", it's not explicit,
3 - you don't add apps to your settings file every day, so there's little to gain.
I think it should be deprecated; since it was never documented, we could even remove it outright.
Best regards,
--
Aymeric Augustin.
[1] http://www.python.org/doc/essays/packages.html - section "Importing * From a Package"
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
> Hello,
>
> I checked the SVN history. This "feature" was never documented, even before the reorganization at r8506. It appears in django/conf/__init__.py when magic-removal is merged (r2809).
>
> We just discussed it on IRC, and the consensus is that it dates back to before Django was open-sourced. It was probably only used at World Online.
>
> In my opinion, it's an anti-feature:
> 1 - It's un-pythonic: in essence, it's equivalent to an filesystem-based implementation of "from <package> import *", which was not rejected in Python for a good reason [1]
Argh! I wanted to write: "which was rejected in Python for a good reason"
I agree with all of this. I would be in favor of simply removing the
wildcard feature with a note in the release notes, unless someone pops
up to argue that it's more widely-used than we think and it should be
deprecated instead, in which case I think a normal deprecation path is a
fine alternative.
Carl
+1 on the strategy.
Jannis
I have created a ticket and a patch to implement Carl's recommendation:
https://code.djangoproject.com/ticket/16247
Could someone review it?