Re: HttpResponse headers interface

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 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 >

Re: HttpResponse headers interface

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 fut

Re: HttpResponse headers interface

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 unnec

Re: HttpResponse headers interface

Hey Nick. > On 16 Jul 2020, at 17:41, Nick Pope 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

Re: HttpResponse headers interface

I would agree that `response.headers` *is* by far clearer especially to those not familiar with Django or coming from other frameworks. As Tom says, we only visually know that setting a key on a response object is for headers because of the key name itself, e.g. "Content-Type". I also think tha

Re: HttpResponse headers interface

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 communit

Re: HttpResponse headers interface

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

Re: HttpResponse headers interface

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

Re: HttpResponse headers interface

The recent change to `url()` was a good example of this; even though it was in a DEP and the docs for a long time it still caused a lot of noise when the deprecation path was finally started. The projects (ok, small sample) I've looked at are only now making this change. Folks will only change

Re: HttpResponse headers interface

> > I would prefer "one right way to do it", but I also don't see a compelling > reason to deprecate the old interface. > For me, the reason to eventually deprecate the old interface is to help new developers learning a new codebase. When these developers have been taught to use response.headers b

Re: HttpResponse headers interface

All this makes a lot of sense. -- 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.

Re: HttpResponse headers interface

I'm in favour of retaining and documenting the old interface, with some kind of sentence pointing at the new one. Carlton posted on the PR that he felt it was a bit paternalistic to recommend one over the other. I don't agree, I think it's important to offer some guidance, especially for new or ret

Re: HttpResponse headers interface

I guess there is still some debate on how to handle the old interface. I'll give my opinion, but I want to make it clear I don't mind that much what we do with it. When I've seen people learning Django, they come across these magical strings you somehow add to the response, but aren't content, tha

Re: HttpResponse headers interface

@Tom looks great, should we add depreciation notices to the response.__gettitem__/del that way there are no 2 right ways to do things? I would probably keep it around until 3.2... I personally like the whole respose.headers it's much more readable. -- You received this message because you are

Re: HttpResponse headers interface

I think the PR has everything now and is ready for review: https://github.com/django/django/pull/13186 On Wed, 15 Jul 2020 at 08:38, Carlton Gibson wrote: > Just to be clear: > > > I think we should keep the old interface. > > I mean as well as adding the new .headers property. (So +1) > (Sorry

Re: HttpResponse headers interface

Just to be clear: > I think we should keep the old interface. I mean as well as adding the new .headers property. (So +1) (Sorry if that was already clear.) On Tuesday, 14 July 2020 16:41:43 UTC+2, Carlton Gibson wrote: > > I think we should keep the old interface. > > The BC concerns are one

Re: HttpResponse headers interface

I think we should keep the old interface. The BC concerns are one point: it's every bit of Django code ever written. To keep __setitem__ &co is a small price to pay not to needlessly break that code. Beyond that though, the proposed API is very nice, but the pendulum will swing back: having r

Re: HttpResponse headers interface

> 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? IMHO, we should eventually take the advice from the zen of Python "There should be

Re: HttpResponse headers interface

Hi all, first off: Thank you for your work, Tom, this will be one of the changes that I will start using immediately and then wonder how I got by without. >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 qu

Re: HttpResponse headers interface

> > 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 als

Re: HttpResponse headers interface

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 usin

Re: HttpResponse headers interface

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 wrote: > I don't find myself using HttpResponse very often, usually I'm using

HttpResponse headers interface

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.hea