>
> Did you intend to have response subclasses for all 57 values of
> http.HTTPStatus?
I hadn't entirely thought it through before implementing :) I agree it's
too much, and many are highly unlikely for Django applications to respond
with, e.g. 203 Non-Authoritative Information.
I'll document th
I think I prefer documenting Berker's suggestion rather than adding more
classes to Django, unless perhaps, they add some additional functionality
as HttpResponseNoContent does.
Did you intend to have response subclasses for all 57 values of
http.HTTPStatus?
On Sunday, August 6, 2017 at 4:17:2
I've made a ticket for this: https://code.djangoproject.com/ticket/28469
On 7 April 2017 at 11:18, Berker Peksağ wrote:
> On Fri, Apr 7, 2017 at 9:54 AM, Adam Johnson wrote:
> > Personally I'd be in favour of adding such classes. It seems against the
> > batteries-included philosophy that Djang
On Fri, Apr 7, 2017 at 9:54 AM, Adam Johnson wrote:
> 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,
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 wrote:
>
> Le 07/04/17
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
I think you'd better write the decision in the document to stop Django
users from making the same feature request in future !
On Thursday, April 6, 2017 at 12:35:41 AM UTC+8, Tim Graham wrote:
>
> Hi, this was already wontfixed here:
> https://code.djangoproject.com/ticket/3362
>
> with the ratio
Hi, this was already wontfixed here:
https://code.djangoproject.com/ticket/3362
with the rationale, "We've decided in the past not to add a new class for
every single response code. You can already pass the status code in when
creating the HttpResponse class, so that can be used in this case."
Every Django view function MUST return an HttpResponse object, sometimes we
just want to send data to the server and don't want to send data back to the
client , this probably lead Python users want to return None instead, however ,
this is not allowed in Django view function, I found HttpRe
