I would be happy to revisit that decision which was made 9 years ago. APIs returning unusual status codes such as 204 are much more common now than they were then. I can't think of a good reason not to add ~10-15 2-line classes.
Marc On 7 April 2017 at 09:37, Brice PARENT <[email protected]> wrote: > > Le 07/04/17 à 08:54, Adam Johnson a écrit : > > Personally I'd be in favour of adding such classes. It seems against the > batteries-included philosophy that Django does not provide all of the > standard codes as classes. I can never remember which codes correspond to > which response types, if I saw status=204 in code it would be a 'magic > number' for me and I'd have to look it up. HttpResponseRedirect and H > ttpResponsePermanentRedirect have been my friends in the past, I can > imagine the same for HttpResponseNoContent. > > +1 > > And there are more than just HttpResponseRedirect and > HttpResponsePermanentRedirect > that are provided by now. > > In django.http.response, you can find : > > HttpResponseRedirect, HttpResponsePermanentRedirect, > HttpResponseNotModified, HttpResponseBadRequest, HttpResponseNotFound, > HttpResponseForbidden, HttpResponseNotAllowed, HttpResponseGone, > HttpResponseServerError > > of which 7 don't embed any code, just the status code (like what is asked > for 204). > > I'm not saying all of them are widely used enough to require an explicit > class declaration (like status code 418) or even would mean anything in the > context of a web framework, but the most common should, at least, be in the > batteries. 204 is an example, but there probably are some others (like 426 > and 505, when the world is switching to https). > > -OR- > > We should at least provide a reversed version of django.http.response. > REASON_PHRASES (which doesn't exist anymore, I think), so that we could > call : > > HttpResponse(status=response_codes.no_content) > > It makes it way less cryptic for both the writer and the readers of the > code. > > -Brice > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/3d69e4e0-0f4a-3f75-3315-3b41c7569ffb%40brice.xyz > <https://groups.google.com/d/msgid/django-developers/3d69e4e0-0f4a-3f75-3315-3b41c7569ffb%40brice.xyz?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1F6qCBTyVhEN0MbkSh2fHJNt%3DFVyMTmQ%3Dn_Knt23HVPZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
