On 12/17/2014 04:39 PM, Russell Keith-Magee wrote: > On Thu, Dec 18, 2014 at 5:03 AM, Aymeric Augustin < > [email protected]> wrote: > >> On 17 déc. 2014, at 21:54, Carl Meyer <[email protected]> wrote: >> >>> So I think there is a backwards-compatibility issue. >> >> Indeed. >> >>> Personally, I would love to decide to just bite this bullet and >>> normalize to lists, but I think it would need to be marked as a >>> backwards-incompatibility in the release notes, and it would certainly >>> bite people. >> >> We can do that. The error is easy to fix if it occurs. Technically >> django.conf.global_settings is a private API. >> >> But I feel guilty to break code just for consistency and aesthetics :-/ >> > > I agree that lists are preferable to tuples. > > As for backwards incompatibility: we can update the new project template, > and we can update the docs; but I don't think we can play the > "global_settings is internal API" card here. The file global_settings might > not be formally documented, but the contents are, and the default settings > provided by Django are documented; and even if they weren't, this is a high > traffic area of the Django API. > > One option for handling existing projects might be to define our own > subclass of list that defines __add__, __iadd__, and __radd__ such that it > will accept a tuple, converting to a list, and raise a DeprecationWarning; > in a later version, we can replace that subclass with a simple list. We > wouldn't document this class, and it would only be used in > global_settings.py. This would cover the most common use case (adding > something to a default setting), and provide a migration path. Thoughts?
This is clever, but on second thought I'm trying to figure out in what
scenario a backwards-compatibility would actually occur here. In the
context of a user's settings modules, global_settings plays no role at
all: you can't add to a global setting default in your settings.py
(unless you've imported global_settings yourself, which is certainly
making use of undocumented internals).
So it seems to me that the only scenario in which this would actually
cause a back-compat problem would be if someone is using a tuple
setting, which they are not setting themselves (and thus are using the
global default), and they are adding to it in their runtime code (not in
their settings file). For instance:
my_ctx_procs = settings.TEMPLATE_CONTEXT_PROCESSORS + ('another',)
The common case of appending to a setting in your settings.py (due to
use of some kind of split-settings) should not be impacted at all.
I guess this is still enough of a backwards-incompatibility that we
should have a deprecation process, but it won't bite nearly as many
people as I'd initially thought it would.
FWIW, I think the subclass-of-list approach is neat enough, I'd be in
favor of going ahead and doing this with that approach, if someone's
motivated to write the patch.
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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/5492164A.4020705%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
