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.
