On 29 août 2014, at 01:33, Tim Graham wrote:
> There have been some other movements to consolidate settings into a dict
> (e.g. #22734 for email settings) so it seems like we prefer this approach
> despite the drawbacks.
Indeed, I've noticed that grouping settings that share a common prefix in
On Saturday, August 30, 2014 12:58:18 PM UTC+2, Aymeric Augustin wrote:
>
> If it weren’t for backwards compatibility, we could recursively merge
> dicts from user settings into defaults settings. For example
> https://github.com/django/django/pull/3138 achieves that in
> override_settings.
>
On 30 août 2014, at 13:39, Florian Apolloner wrote:
> And what would that give us? if I want override FOO['BAR'] where from would I
> override FOO with that merging behavior in place?
>From your settings file.
--
Aymeric.
--
You received this message because you are subscribed to the Goo
On Saturday, August 30, 2014 1:58:07 PM UTC+2, Aymeric Augustin wrote:
>
> On 30 août 2014, at 13:39, Florian Apolloner > wrote:
>
> > And what would that give us? if I want override FOO['BAR'] where from
> would I override FOO with that merging behavior in place?
>
> From your settings file.
The merging is between the final user settings and global_settings. The
advantage is not having to redeclare all the keys in a setting like:
SECURITY_MIDDLEWARE = {
'HSTS_SECONDS': 0,
'HSTS_INCLUDE_SUBDOMAINS': False,
'CONTENT_TYPE_NOSNIFF': False,
'BROWSER_XSS_FILTER': False,
On Saturday, August 30, 2014 2:48:10 PM UTC+2, Tim Graham wrote:
>
> If base.py adds CONTENT_TYPE_NOSNIFF and prod.py wants to add
> HSTS_SECONDS, it would look like this:
>
Oh, that makes sense, I was so focused on "extending" that I didn't see
that base.py could define a minimal dict itself
I still don't see the benefit to a dictionary. It's helpful for DATABASES
and CACHES because there can be multiple of them.
> It ensures that related settings remain grouped together.
It seems to me a common SECURITY_ prefix should be good enough
- It satisfies our craving for DRY
A _tiny_ more
On 30 août 2014, at 17:35, Collin Anderson wrote:
> - It satisfies our craving for DRY
> A _tiny_ more DRY, but it's _more_ code in your settings.py. Who wants to
> type out all those quotes?
>
> - It artificially lowers len(dir(django.conf.global_settings)).
> How is this helpful?
These two a
I was initially indifferent about putting the django-secure settings in
a dictionary, but the more I've thought about the more I feel Collin is
correct; there is no real benefit (just an arguable sense of "tidiness")
and there are several negatives (more verbosity in documentation, check
warnings,
-1 on using dictionaries to group somewhat related settings. Dicts make it
much harder to override specific keys - and implementing a dict merge to
get around a problem that we're creating ourselves for reasons
of perceived attractiveness seems a little backwards. Mergingi
If I want to simply
On Sat, Aug 30, 2014 at 8:33 PM, Josh Smeaton
wrote:
>
> I think the problem becomes more pronounced when you want to override a
> single sub-setting between your different environments:
>
> # base.py
>
> SECURITY_MIDDLEWARE = {
> 'HSTS_SECONDS': 10,
> 'HSTS_INCLUDE_SUBDOMAINS': True,
>
The way the discussion has gone, I think I favor individual settings over
settings grouped in a dictionary in this case.
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
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 patter
13 matches
Mail list logo
