Ah, I think I just misread your earlier mail then. Sorry about the confusion!
Tom On Thu, 16 Jul 2020 at 20:44, Carlton Gibson <carlton.gib...@gmail.com> wrote: > Hey Tom, > > The movement of the discussion was (or at least seemed to be, prompting > concern) to eventually deprecate and remove, even if on a longer time > scale. It’s that that raised the red flags I think. > > Folks have been stung before: a new feature is introduced with a “May be > deprecated in future”, rhetorically implying “don’t worry, it won’t really > be deprecated”, but then inevitably it is, and then there’s the breaking > change. > > (That we didn’t remove the feature immediately doesn’t change the > situation for the end user — I think James made a similar point in the > discussion around url() about NOT doing extended deprecations: it just > delays the pain, it we can’t accept it straight out, maybe the change > wasn’t so harmless.) > > Currently the patch says "Both interfaces will continue to be supported.” > As long as that’s not changed to any version of "May be deprecated in > future”[*] then super, nice, I like it. > > > As long as we agree to not deprecate it, which I thought we had… > > My email this afternoon was prompted by the concern that this wasn’t > agreed, and the consequences of that. > > I hope all that make sense: I feel like I’m saying the same things again — > perhaps I’m not being clear. > > I like the feature; as far as I am aware no-one has said they don’t; if > we’re not going to break the existing interface then concerns are allayed I > think. > > Kind Regards, > > Carlton > > > [*] See previous points about, “let’s talk about it when Django is 30” > > On 16 Jul 2020, at 19:12, Tom Carrick <t...@carrick.eu> wrote: > > But the proposed patch doesn't break any existing code, does it? As far as > I can tell, the old interface works the same as it always did. As long as > we agree to not deprecate it, which I thought we had, then nothing is > breaking. Changing code in other places was at Adam's suggestion, but it's > unnecessary, it can be removed without consequence. > > Perhaps I'm missing something? > > Tom > > On Thu, 16 Jul 2020 at 18:48, Carlton Gibson <carlton.gib...@gmail.com> > wrote: > >> Hey Nick. >> >> On 16 Jul 2020, at 17:41, Nick Pope <nickpope1...@gmail.com> wrote: >> >> I honestly thought the approach Carlton mentioned in >> https://github.com/django/django/pull/13186#discussion_r454956921 struck >> the correct balance and we could even, if desired, highlight in the release >> notes for the new `response.headers` that the old approach has not gone >> away such that developers do not need to rush to update their code. As >> highlighted by the examples above, it feels like there is precedent for >> that. Also if the data model approach is plumbed in to use `.headers` as in >> the proposed implementation, I don't see this as being a burden to maintain. >> >> Please let's be pragmatic about this stuff and not be driven to adhering >> to "one way to do it" as an extremist ideology rather than a laudable >> preference. >> >> >> This was exactly my thought. Add the new .headers feature — I don’t think >> there’s anyone saying it isn’t nicer in isolation — but leave the existing >> interface alone. >> >> But the concern was expressed to me that deprecation and eventual removal >> of the original way of doing it (under any timescale, as we saw just >> recently with `url`) involves updating every line of Django that ever set >> response header. It’s THAT burden that’s at issue. It would be too much: at >> that point the new niceness of .headers doesn’t justify the expense.[*] >> >> If we can add .headers without the breaking change (under any timescale — >> I joked with Adam that Django is 15, so perhaps we could discuss it when >> it’s 30…) then I’m all for it. I agree the implementation of `__setitem__` >> &co doesn’t add a maintenance burden. >> >> Not breaking existing code is our biggest selling point. >> >> Kind Regards, >> >> Carlton >> >> >> >> [*] Hopefully that’s not extremist…—unless cost-benefit analysis is >> extremist these days, which it could be 😀 >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/ED88B9B4-D474-4562-BFDB-4362B7168E56%40gmail.com >> <https://groups.google.com/d/msgid/django-developers/ED88B9B4-D474-4562-BFDB-4362B7168E56%40gmail.com?utm_medium=email&utm_source=footer> >> . >> > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZP-CrA1DbKJa5Jp6tAFW-Mh3VRka5Cfy868dvcaQt8rw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZP-CrA1DbKJa5Jp6tAFW-Mh3VRka5Cfy868dvcaQt8rw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/235A1B7D-59DB-4A67-977F-63DC04CB30FD%40gmail.com > <https://groups.google.com/d/msgid/django-developers/235A1B7D-59DB-4A67-977F-63DC04CB30FD%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHoz%3DMZ5s-1yZxLdyb0J7WsnPfKAp3brTt_KtfL-fXeZyubNdw%40mail.gmail.com.
