[Django] #33683: Document HttpResponseBase and allow import from django.http
Django
------------------------------------------------+------------------------
Reporter: Collin Anderson | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: dev
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
HttpResponseBase shouldn't be used directly for creating responses, but
it's super useful for type-checking, so I think we should document and
allow import from django.http.
--
Ticket URL: <https://code.djangoproject.com/ticket/33683>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Collin Anderson | Owner: nobody
Cleanup/optimization |
Component: HTTP handling | Version: dev
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Collin Anderson):
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/15667
--
Ticket URL: <https://code.djangoproject.com/ticket/33683#comment:1>
Django
Reporter: Collin Anderson | Owner: nobody
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* stage: Unreviewed => Accepted
Comment:
Hey Collin.
Question: rather than exposing the base class, should we not be defining a
protocol here, that you'd then use for type annotations? (Does Python
typing allow... erm... ''retrofitting'' — that's probably not the word —
protocol conformance? 🤔)
--
Ticket URL: <https://code.djangoproject.com/ticket/33683#comment:2>
Django
--------------------------------------+------------------------------------
Reporter: Collin Anderson | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by Collin Anderson):
I don't really know what you mean by "protocol". Could you explain more or
give an example of another "protocol"?
My use case is I have a view that wraps `django.views.static.serve`, which
returns `HttpResponseBase` according to `django-stubs`
https://github.com/typeddjango/django-stubs/blob/master/django-
stubs/views/static.pyi#L8.
So my view that wraps `serve` needs also needs to be annotated as
returning `HttpResponseBase`, so it would nice if `HttpResponseBase` was
part of the official api, rather than being undocumented.
--
Ticket URL: <https://code.djangoproject.com/ticket/33683#comment:3>
Django
--------------------------------------+------------------------------------
Reporter: Collin Anderson | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by Carlton Gibson):
Hey Colin.
There's a PEP here: [https://peps.python.org/pep-0544/ PEP 544 –
Protocols: Structural Subtyping (Static Duck Typing)]
The idea roughly being that you declare a protocol, which any class can
conform to, and use that in your annotations, rather than requiring a
specific subclass, since folks are used to passing any kind of object that
responds appropriately.
> Does Python typing allow... erm... retrofitting — that's probably not
the word — protocol conformance? 🤔
Reading from the PEP, on [https://peps.python.org/pep-0544/#explicitly-
declaring-implementation Explicitly declaring implementation]:
> Static analysis tools are expected to automatically detect that a class
implements a given protocol. So while it’s possible to subclass a protocol
explicitly, it’s not necessary to do so for the sake of type-checking.
So... testing needed but... one would hope that a suitable Protocol
definition would satisfy the type-checkers, without needing changes
everywhere in the existing code.
With `runtime_checkable()` it looks like that's usable with `isinstance()`
too which might help avoid issues like #33362.
None of this is necessary here — more just thinking how we move forward:
documenting `HttpResponseBase` is fine I think.
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/33683#comment:4>
Django
--------------------------------------+------------------------------------
Reporter: Collin Anderson | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by Collin Anderson):
Ahh, I think. see what you're saying now. Though yeah I think it's
ultimately up to the stubs projects to figure out what sort of type
framework to use (protocol vs implementation, etc), unless we do actually
want type annotations in Django. But maybe there's a chance documenting
`HttpResponseBase` pushes the type-checking ecosystem in a direction we
don't necessarily want to go, so I could see holding off on documenting
it.
--
Ticket URL: <https://code.djangoproject.com/ticket/33683#comment:5>
Django
Reporter: Collin Anderson | Owner: nobody
Cleanup/optimization |
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/33683#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: Collin Anderson | Owner: nobody
Cleanup/optimization |
Component: HTTP handling | Version: dev
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"2a5d2eefc751be012fdebd75d8177c42bf5a76fc" 2a5d2ee]:
{{{
#!CommitTicketReference repository=""
revision="2a5d2eefc751be012fdebd75d8177c42bf5a76fc"
Fixed #33683 -- Document HttpResponseBase and allow import from
django.http
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33683#comment:7>