The concern is the backwards incompatibility. I do see the reasons for the new approach. I accept that it’s easier to grok if you don’t know Django already — “principal of least astonishment” I think you opened with.
I just can’t balance those gains against forcing a change on the entire community. It just doesn’t balance. (And being negative, as soon as you do know Django the new proposal is more verbose, so not to be preferred.) I had thought that it would be additive but the API stability policy is quite clear on the “one way of doing things”. Thus, as much as I do like the idea, I don’t think we can do this. On Thu, 16 Jul 2020 at 15:39, Tom Carrick <t...@carrick.eu> wrote: > Hmm. I do think that Python's data model is a Good Thing. Where we might > disagree is that I don't think this is an appropriate use of it.I'll try to > illustrate with an example. Consider this code: > > response = HttpResponse() > response['foo'] = 'bar' > > Now, if I try to look at this code without context, putting my Django > knowledge to the back of my head, intuitively, this doesn't look like I'm > setting a header. To me it actually looks more like my response is JSON > (increasingly common these days) and I'm setting the 'foo' key on it to > 'bar'. Now, is this likely to happen and cause confusion? Probably not, > since we tend to spell out our headers such as Content-Type rather than > content-type, and custom headers tend to be prefixed with 'X-'. But I do > think there is potential confusion, especially to beginners or perhaps > people who know a little frontend development and expect any request to > return JSON, and perhaps haven't had to interact with headers as their > libraries take care of them. > > However, the reason I bring this up isn't so much this potential for > confusion, but more this: When I think about a HTTP request, 99% of the > time, I'm thinking about the response content. Only rarely am I ever > thinking about the headers. Usually interacting with headers is abstracted > away in middleware or some other place. So why should setting a key on the > response set something on the headers? It seems unintuitive to me. > > Personally, I think that is enough to meet the bar of "clearly superior", > but I'm aware I don't have the only opinion. > > Another thing this is useful for is that it's actually possible (in a > documented, public way) to see all the response headers. Of course the > server could modify this, but it's still useful when debugging to see what > Django is setting, and right now the only way I can think to do this is to > look at `response._headers`, and I'd rather not be using undocumented APIs. > > If the concern is primarily about the diff size, it's quite trivial (if we > decide to keep the existing API as-is forever and just add the new > interface on top) to drop the commits changing those and just add tests for > the new interface. It is then purely additive in the sense that the old API > works just the same and isn't going anywhere. > > Regardless, I'm happy to go wherever the consensus is. > > Cheers, > Tom > > On Thu, 16 Jul 2020 at 14:25, Carlton Gibson <carlton.gib...@gmail.com> > wrote: > >> 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 >> <https://groups.google.com/d/msgid/django-developers/98cba197-d079-4f7d-84e5-18308509a99ao%40googlegroups.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%3DMaBbPUw7dcTeH2M-PmLgwUb4oaLsdQi%2Bz8hCVMpCgtbYQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAHoz%3DMaBbPUw7dcTeH2M-PmLgwUb4oaLsdQi%2Bz8hCVMpCgtbYQ%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/CAJwKpyS6ADxqtGX_Mx%2BmPZFb3Nmxo5cDmsNxoTWGiWgQx9wK2w%40mail.gmail.com.
