Hi Shai, On 09/01/2014 01:15 AM, Shai Berger wrote: > This thread has had very little to do with django-secure for some time...
Thanks :-) > On Sunday 31 August 2014 18:07:04 Carl Meyer wrote: >> >> In the case of the email settings, I think introducing a deprecation >> that requires people to update their settings files, for zero gain in >> capability, is a much bigger negative than any of the ones mentioned >> above, and should in itself be enough to scuttle the proposal. As I said >> on the ticket, if a significant new capability were introduced that >> required a change to the settings structure (e.g. multiple email >> backends configured at once, which is why CACHES and DATABASES are now >> dictionaries), that might provide enough benefit to justify a deprecation. >> > > A case in point is a change that was introduced in 1.7 -- putting the TEST > settings of databases into an inner dict. When it was brought up, all > responses were positive. The only negatives I've seen since then had to do > with the deprecation -- with the initial implementation, it was not to make a > settings file with test-settings which would work without warnings on both > 1.6 > and 1.7. This has been since corrected (by allowing new and old to co-exist > when they are equivalent). > > There was no gain in functionality, just the logical grouping -- and that, > itself, is somewhat limited (because the settings at issue were already in a > dictionary). There were some simplifications in backend code (esp. the Oracle > backend, which uses more of these settings than other backends). > > On the other hand, test settings are less popular for defaults in multiple- > level user settings, so some considerations may be different. > > As I said, everybody who commented on it back then liked it. I still like it > in that context (though, as I mostly work on the Oracle backend, I'm > biased). > If we now decide that we globally don't like the concept, perhaps it is not > too late to revert it. Or perhaps the decision shouldn't be so global. I would not say that I "globally don't like the concept"; just that it's not an obvious win in all cases; there are tradeoffs. So yes, I would advocate for "the decision shouldn't be so global", in either direction. I think a dictionary is good design in the case of DATABASES and CACHES, and there will probably be future cases where it is also well-justified. My objection in the case of the email settings is primarily that the benefit is not worth the backwards-incompatibility, and in the case of django-secure it's that the settings aren't closely related enough to justify the downsides. I'm slightly in favor of the database TEST_* change, despite the backwards incompatibility, for these reasons that don't apply in the other cases (roughly in order of importance): a) the TEST_* settings were rapidly expanding to become a full copy of the normal per-database settings, and it's logical that they would be: really you're just defining another database to be used in test. So there's an additional conceptual simplicity (and possibly code simplification too, though I haven't looked at the commit) achieved by making it look more like "just another database" configuration. b) The database TEST_* settings are, I think, less commonly used than the email settings, so the backwards-compatibility impact is smaller. c) The TEST_* settings are less likely to be overridden in a multiple-user-settings scenario (as you mentioned), and have no default values (so there's no issue with partial override of defaults). d) The settings were already contained within the DATABASES dictionary, so if you were trying to override them you were already dealing with the added complexity of overriding bits of dicts. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/54061434.3040808%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
