Hi Claude,
On 08/31/2014 12:08 PM, Claude Paroz wrote:
> The situation about multiple user settings file is absolutely not
> changed by that patch. If you import from a parent settings file, it's
> still your choice to either overwrite the dictionary or update it, no
> magics happen at all at this stage.
>
> The magics merge effect is only between global settings and user
> settings, so you could define:
>
> EMAIL = {'USE_SSL': True}
>
> without clearing other EMAIL keys from the default global settings.I agree; I tried to make the same distinction in my last mail in this thread. > Carl, you mention several other arguments which I don't understand: > more verbosity in documentation, check warnings, For instance, the "check --deploy" warnings would need to say "to enable HSTS, you should set the 'HSTS_SECONDS' key of the SECURE_CONFIG setting to something non-zero", rather than simply "you should set the SECURE_HSTS_SECONDS setting to something non-zero." Or it could be "you should set the SECURE_CONFIG['HSTS_SECONDS'] setting", which is not as verbose but now requires a bunch of punctuation. Every reference to these settings in documentation or in check warnings becomes similarly more verbose. > and settings files, > more complex to work with in settings-override scenarios. Figuring out how to correctly override dictionary settings (even between two user-settings levels, with .update()) is more complex than overriding simple flat settings. I don't think either of these are big problems or deal-breakers, only that they are negatives which should be balanced by some compelling benefit. > You may look at the pull request > https://github.com/django/django/pull/2836 to see if any of the above > are confirmed or not in that scenario (email settings). I think the pull request confirms a slight increase in the verbosity and punctuation required both in referring to the settings in documentation, and using the settings in code. And the fact that it required #23384 to be committed first confirms that it also is "more complex to work with in settings-override scenarios." > Yes, it's a design choice to make, judging if a bit of "magic" merging > justifies or not having better logically-grouped settings. Keep also in > mind that the original use-case (apart from django-secure new settings) > was the addition of two new email-related settings (#20743). I don't find "better logically-grouped settings" a compelling benefit. Anyone who cares about having their settings logically grouped can easily group them in their settings file (and probably already does) without being forced to do so by having them in a dictionary. 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. I don't think #20743 provides a rationale for moving the email settings into a dictionary structure, either. I'm not a fan of global settings in general, but when a particular subsystem (e.g. email) is already configured via global settings, adding a couple more knobs to that configuration isn't a significant problem. Adding those knobs inside a dictionary (which is still a process global) rather than as new top-level settings doesn't gain anything worthwhile, as far as I can see. As Aymeric said, `len(dir(django.conf.global_settings))` is not a useful metric. We don't really have "fewer settings" if we hide them inside dictionaries; we just have settings that are slightly harder to work with. > Once again, I'm not advocating for dictionary settings, only for fare > debate :-) I hope you found this email fair ;-) Carl
signature.asc
Description: OpenPGP digital signature
