#24121: Provide a better repr() experience
------------------------------+------------------------------------
Reporter: Keryn Knight | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
------------------------------+------------------------------------
Description changed by Mariusz Felisiak:
Old description:
> For a long time, Django has shipped with the debug 500 handler, which
> defaults to a view where "local vars" for every stack frame can be
> expanded and inspected to see the internal state at the various points in
> the stack trace.
>
> Between that renderer, the heavy usage of `django-debug-toolbar`, which
> ships with a template context inspector, and my preference throwing `pdb`
> everywhere, there is a notable lack of a good `repr()` experience in much
> of Django, both in debugging public API (that is, the bits a user will
> use and encounter), and internals that might be exposed, or could
> otherwise be served better by having a repr that says something more than
> it's address/id.
>
> A couple of previous tickets have addressed this in minor, one off ways -
> #23167, #22906, #22531 - but as I've begun collecting places they could
> supply useful info as I spot them in my stuff, they've become a
> hodgepodge across a number of modules.
>
> For example, a couple I've got implemented:
> {{{
> <TemplateResponse status_code=200, charset=utf-8, _is_rendered=False>
>
> <LoaderOrigin name=/absolute/path/to/templates/admin/change_list.html,
> loadname=admin/change_list.html>
>
> <FilterExpression var=u'admin/change_list.html', filters=[]>
> }}}
> All of which, IMHO, provide a more useful context in which to evaluate
> state.
>
> The branch I have implemented my reprs in is in no way merge ready yet,
> partially because there's no tests, and it'd need rebasing & squashing,
> but also because there are some parts I'd like to see reprs on but
> haven't landed on a good way to do so.
> An example being the concept of a `Loader`, which currently has no repr()
> and thus shows up as `<path.to.cached.Loader … 0xETC>` which at least
> tells us which loader is being referenced. Given the convention so far
> for reprs() is just the class name (rather than module + class), the fact
> all Loaders (and now Engines) all share the same class name means in
> exposing more useful internal state we lose knowledge of the loader in
> question's module namespace.
>
> As I write this, I've got at least rudimentary (as in, it was possibly to
> replace the 0x... with at least one object-state variable) reprs for:
> * `StaticNode`
> * `BlockTranslateNode`
> * `URLNode`
> * `Token`
> * `Lexer`
> * `Parser`
> * `FilterExpression`
> * `RedirectFallbackMiddleware`
> * `MessageMiddleware`
> * `RemoteUserMiddleware`
> * `Col`
> * `Lookup`
> * `BaseDatabaseWrapper`
> * `SQLCompiler`
> * `JoinPromoter`
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * `PermWrapper`
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * `CsrfViewMiddleware`
> * `Response`
> * `SimpleTemplateResponse`
> * `TemplateResponse`
> * `AdminSite`
> * `ModelAdmin`
> * `Origin`
> * `TemplateOrigin`
> * `BlockContext`
> * `IncludeNode`
> * `Template`/`Engine` (would need work still I think)
>
> If accepted, this ticket could just track whatever I can end up getting
> reviewed/merged, or it could be a meta-ticket for accepting as a
> principle, and I could spin off tickets for more targeted areas.
New description:
For a long time, Django has shipped with the debug 500 handler, which
defaults to a view where "local vars" for every stack frame can be
expanded and inspected to see the internal state at the various points in
the stack trace.
Between that renderer, the heavy usage of `django-debug-toolbar`, which
ships with a template context inspector, and my preference throwing `pdb`
everywhere, there is a notable lack of a good `repr()` experience in much
of Django, both in debugging public API (that is, the bits a user will use
and encounter), and internals that might be exposed, or could otherwise be
served better by having a repr that says something more than it's
address/id.
A couple of previous tickets have addressed this in minor, one off ways -
#23167, #22906, #22531 - but as I've begun collecting places they could
supply useful info as I spot them in my stuff, they've become a hodgepodge
across a number of modules.
For example, a couple I've got implemented:
{{{
<TemplateResponse status_code=200, charset=utf-8, _is_rendered=False>
<LoaderOrigin name=/absolute/path/to/templates/admin/change_list.html,
loadname=admin/change_list.html>
<FilterExpression var=u'admin/change_list.html', filters=[]>
}}}
All of which, IMHO, provide a more useful context in which to evaluate
state.
The branch I have implemented my reprs in is in no way merge ready yet,
partially because there's no tests, and it'd need rebasing & squashing,
but also because there are some parts I'd like to see reprs on but haven't
landed on a good way to do so.
An example being the concept of a `Loader`, which currently has no repr()
and thus shows up as `<path.to.cached.Loader … 0xETC>` which at least
tells us which loader is being referenced. Given the convention so far for
reprs() is just the class name (rather than module + class), the fact all
Loaders (and now Engines) all share the same class name means in exposing
more useful internal state we lose knowledge of the loader in question's
module namespace.
As I write this, I've got at least rudimentary (as in, it was possibly to
replace the 0x... with at least one object-state variable) reprs for:
* `StaticNode`
* `BlockTranslateNode`
* `URLNode`
* ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
* ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
* ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
* ~~`FilterExpression`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
* `RedirectFallbackMiddleware`
* `MessageMiddleware`
* `RemoteUserMiddleware`
* `Col`
* `Lookup`
* `BaseDatabaseWrapper`
* `SQLCompiler`
* `JoinPromoter`
* ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
added in c96f11257baf43188ff9daeddab3221992925c85
* ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
9c40f01a66bd15457e10a0bbf28c803968b5dabb
* ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
* `PermWrapper`
* `SessionStorage`
* `CookieStorage`
* `FallbackStorage`
* `ChangeList`
* `AdminForm`
* `InlineAdminFormSet`
* `CsrfViewMiddleware`
* `Response`
* `SimpleTemplateResponse`
* `TemplateResponse`
* `AdminSite`
* `ModelAdmin`
* `Origin`
* `TemplateOrigin`
* `BlockContext`
* `IncludeNode`
* `Template`/`Engine` (would need work still I think)
If accepted, this ticket could just track whatever I can end up getting
reviewed/merged, or it could be a meta-ticket for accepting as a
principle, and I could spin off tickets for more targeted areas.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24121#comment:11>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.087bae306abcc3b481790b687ed648c0%40djangoproject.com.
