> > I'm wondering though, if we should prefer this interface over the old one, > as it's a bit more explicit in my view. I'd be happy to go through the docs > and change the examples to using the headers attribute directly. >
I think it's preferable. The old interface was so unclear. It would also be good to update as many of Django's tests as possible, at least those that can be found with a regex, e.g. resp(onse)?\[['"] . > don't see a reason to deprecate it at all just now (though perhaps in _my_ > ideal world that would happen at some point) Yes, this will probably need to live 'forever' for backwards compatibility concerns. The same as for request.GET etc. as per https://groups.google.com/d/msg/django-developers/Kx8BfU-z4_E/gJBuGeZTBwAJ . One further small addition, I think it would be good to be able to pass > headers into the HttpResponse object > I'm also behind that. A quick survey shows that Flask, Pyramid, and Starlette all allow passing headers in response construction. I think a separate ticket is warranted, it would require updating yet more docs/tests, so it would be good to merge step one before embarking on step two. On Tue, 14 Jul 2020 at 12:58, Tom Carrick <t...@carrick.eu> wrote: > I've pushed a proof of concept here: > https://github.com/django/django/pull/13186 > > I decided to do a bit more than I initially intended. It seems like the > headers can be stored as a public interface and single source of truth now, > rather than just adding an extra public property based on it, by using a > slightly modified CaseInsensitiveMapping. > > Perhaps I'm missing some reason - and if there is one, let me know - that > this shouldn't be a public, documented interface, but I'm not sure what > that is. > > If this all seems good, I'll write up docs and tests (all current tests > seem to be passing). I'm wondering though, if we should prefer this > interface over the old one, as it's a bit more explicit in my view. I'd be > happy to go through the docs and change the examples to using the headers > attribute directly. I don't see a reason to deprecate it at all just now > (though perhaps in _my_ ideal world that would happen at some point), but > I'm not sure if it's worth keeping the current interface in the > documentation at all? > > One further small addition, I think it would be good to be able to pass > headers into the HttpResponse object, so rather than doing: > > response = HttpResponse() > response['foo'] = 'bar' > return response > > You could instead return HttpResponse(headers={'foo': 'bar'}) > > Perhaps that's better in a separate ticket / PR, but it seems like a > minimal amount of effort to add it at the same time. > > Cheers, > Tom > > On Wed, 17 Jun 2020 at 21:53, Adam Johnson <m...@adamj.eu> wrote: > >> I have also found this a little odd when writing tests. It would >> certainly make it easier to write both normal Django code and tests, and >> it's a small addition, so +1 from me. >> >> On Wed, 17 Jun 2020 at 15:35, Tom Carrick <t...@carrick.eu> wrote: >> >>> I don't find myself using HttpResponse very often, usually I'm using >>> DRF's Responses. But today I needed to use one, and as I was writing tests, >>> I ended up somewhat astonished, so with the principle of least astonishment >>> in mind... I had anticipated that I could check the headers with >>> `response.headers`, similar to how the new request.headers >>> <https://code.djangoproject.com/ticket/20147> works, but apparently >>> this is not the case. After reading the docs, I found out that I should >>> just treat the HttpResponse object itself as if it were a dictionary of >>> headers. This seems very strange to me, it's not what I expect, but maybe >>> I'm in the minority. >>> >>> I have no interest in deprecating the old API, but it would be nice if >>> the headers were all accessible from a simple headers dict, and perhaps >>> make this the source of truth, allowing access with any casing but >>> preserving the original casing for output. It looks like what is currently >>> HttpResponse._headers was once HttpRequest.headers, but this was 13 >>> years ago <https://code.djangoproject.com/ticket/5479>, I don't think >>> it'd be confusing to add the property back as something different. >>> >>> -- >>> 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%3DMa9-m%2Bfqj0wqzQ7qW5Aiw3POHtNOp2NTBaHeP_ux5FhLg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMa9-m%2Bfqj0wqzQ7qW5Aiw3POHtNOp2NTBaHeP_ux5FhLg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Adam >> >> -- >> 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/CAMyDDM2HCJKbW%3D3dNkB7BDV4R6eSAGokg%3DPENFd%3D%2BhNwaTt9OQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2HCJKbW%3D3dNkB7BDV4R6eSAGokg%3DPENFd%3D%2BhNwaTt9OQ%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/CAHoz%3DMa7QfRHgaT7iJTAqnpzVo6ZoHKcdLVp8dER%2BCus0G_wpw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMa7QfRHgaT7iJTAqnpzVo6ZoHKcdLVp8dER%2BCus0G_wpw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Adam -- 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/CAMyDDM1JiosqN9Qs7hQmoAkWR%3DdcxmyksWtaH5W%3DvfGCcLTzBw%40mail.gmail.com.
