On Thu, Dec 18, 2014 at 7:48 AM, Carl Meyer <c...@oddbird.net> wrote:
>
> On 12/17/2014 04:39 PM, Russell Keith-Magee wrote:
> > On Thu, Dec 18, 2014 at 5:03 AM, Aymeric Augustin <
> > aymeric.augus...@polytechnique.org> wrote:
> >
> >> On 17 déc. 2014, at 21:54, Carl Meyer <c...@oddbird.net> 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
>
That's a fair point. The benefit for an __add__ definition is likely to be
a lot smaller than I originally thought.
The only place I can think that it might pop up is in older (pre
@override_settings) test harnesses; that said, a failure during test isn't
a major inconvenience
So - I retract my suggestion - I think I can live with just documenting
this as a backwards compatibility.
Yours,
Russ Magee %-)
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAJxq84_Esoe0u69D9Y0MkP5dEubkhgSRR_jAxkf-sXCsZpVegA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
