On 08/30/2014 07:28 PM, Tim Graham wrote:
> If we drop magical merging of dictionary settings (which seems like it
> will cause more confusion), a user's options for customizing a single
> key in settings are:
> 1. Redefine the entire dictionary in a project's settings
> 2. Use the following pattern to update a subset of keys:
>
> from django.conf.global_settings import SECURITY_MIDDLEWARE
>
> SECURITY_MIDDLEWARE.update({
> 'SSL_HOST': 'staging.my.host.com <http://staging.my.host.com/>',
> })
>
> We have admonitions in the docs that users should not import from
> global_settings and I don't care for 1 either.Michael is talking about the "multiple levels of inherited user settings" situation, where I agree with him that dict.update() is generally a good-enough solution, and the merge feature committed in https://github.com/django/django/commit/66757fee7e921ad4c35e0b3f80c25e026100b31c to fix #23384 doesn't help anyway. When it comes to user settings extending a built-in dict default, I agree with you that there's currently no good solution. But I'm also not sure it's a problem that needed a solution. I can't think of a time when I've wanted to add a second CACHE or DATABASE, while wanting to use the built-in default one as well. It's not a problem I've heard from anyone else either. And if I did have that problem, I would prefer explicitly repeating the configuration for the default, rather than relying on implicit special treatment of dict settings. So on the whole I'd probably favor reverting #23384, just because it's magical and implicit and I don't think it solves a significant problem in practice. But I don't feel strongly about it. Of course, if we're going to start aggressively grouping more built-in settings into dictionaries, that would provide justification for #23384. But I think the simpler and better answer is "let's not do that." Flat simple settings are just easier to deal with, and don't require any implicit merge behaviors. Carl
signature.asc
Description: OpenPGP digital signature
