Some concerns were expressed privately to me privately in the week about the change here.
I was thinking about it, and re-reading the API Stability document https://docs.djangoproject.com/en/3.0/misc/api-stability/. The more I look at it, the less convinced I am that the proposal here meets the "when we discover clearly superior ways to do things" criterion. Yes, I think, if we were starting from scratch, we'd probably put headers in a mapping attached to the response, so the request.headers here proposed. I think that probably is (definitely is?) easier for a beginner to grok. But looking at the diff β where all the changes are just from: response['Content-Disposition'] = 'attachment; filename="somefilename.csv"' to: response.headers['Content-Disposition'] = 'attachment; filename="somefilename.csv"' I can't see that this is clearly superior, to just having the response itself act as said mapping. I learnt Python through Django. This exact case was my first expose to the Python Data Model. Oh, objects can act like dictionaries. Cool. Didn't think about it again for half a dozen years. But it wasn't so difficult. The s/response/response.headers/g (from one POV) just looks like more code, despite the initial "Yeah, sounds good." Then I come to the βone way to do it. OK, I get that. But I look at the prospect of forcing every project that ever set an HTTP header to have to update. I look again at the "clearly superior", and I have to conclude that the change isn't justfied. That's too bigger cost for too small a gain. So, despite earlier enthusiasm, I have to lean towards a -1 here. Like request.headers, I initially took this as a purely additive gain, but that's not compatible with the goals expressed in the API Stability policy. So I think we should pass. Not easy. Django is in a good place: we're at the point where it's easy to update, and that's the expectation. The API Stability policy (and it's enforcement) is largely responsible for that. It's important not to forget. We on this list see a *little* change as a nothing. Across the massive install base it's anything but. David's mention of url() is a good one β for each complaint we see here, and we saw a few, there will be a thousand we don't β people just do the work, but that's not something we should impose lightly. The are a couple of good additions to take: * Setting headers via an init kwarg would be cool. * Maybe the CaseInsenstiveMapping is worth using too. (Not so sure what the benefits are here.) Kind Regards, Carlton -- 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/98cba197-d079-4f7d-84e5-18308509a99ao%40googlegroups.com.
