subject:"Re\: \[Django\] #24121\: Provide a better repr\(\) experience"

Re: [Django] #24121: Provide a better repr() experience

2024-09-17 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Comment (by Sarah Boyce <42296566+sarahboyce@…>):

 In [changeset:"9ca1f6eff6f19d1ae074d289c6c4209073351805" 9ca1f6ef]:
 {{{#!CommitTicketReference repository=""
 revision="9ca1f6eff6f19d1ae074d289c6c4209073351805"
 Refs #373, Refs #24121 -- Added ColPairs.__repr__().
 }}}
-- 
Ticket URL: 
Django 
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/01070191fff26bda-e2f49175-abd7-4dd3-bb75-ca7fd9d23da1-00%40eu-central-1.amazonses.com.

Re: [Django] #24121: Provide a better repr() experience

2023-08-24 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"7bba231b67996fce294f257e1316748cc4ef299a" 7bba231b]:
 {{{
 #!CommitTicketReference repository=""
 revision="7bba231b67996fce294f257e1316748cc4ef299a"
 Refs #24121 -- Added __repr__() to Message.
 }}}

-- 
Ticket URL: 
Django 
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/0107018a26cbc1ae-72cfd2de-6f7f-4298-b013-42c755b414d8-00%40eu-central-1.amazonses.com.

Re: [Django] #24121: Provide a better repr() experience

2021-12-21 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"e95e6425ac354b8fb0c24580b740dbdc2ea72bd6" e95e642]:
 {{{
 #!CommitTicketReference repository=""
 revision="e95e6425ac354b8fb0c24580b740dbdc2ea72bd6"
 Refs #24121 -- Added __repr__() to BaseFormSet.
 }}}

-- 
Ticket URL: 
Django 
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.1ba0e4807c21342df3e074fd404597d7%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-11-18 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => fixed


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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * ~~`BlockTranslateNode`~~ added in
> 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * ~~`BaseStorage`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`ChangeList`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`AdminForm`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`AdminSite`~~ added in e4da3654367cd5f5c06ab109ece0042631faaa02
> * ~~`ModelAdmin`~~ added in e4da3654367cd5f5c06ab109ece0042631faaa02
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`BlockContext`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`IncludeNode`~~ added in 66ed03e7c9ae4cd754aa918c6

Re: [Django] #24121: Provide a better repr() experience

2021-11-18 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"6fa2930573ff862a7f8ae8a11aa8bb7253fddeb7" 6fa29305]:
 {{{
 #!CommitTicketReference repository=""
 revision="6fa2930573ff862a7f8ae8a11aa8bb7253fddeb7"
 Refs #24121 -- Added __repr__() to BaseDatabaseWrapper, JoinPromoter, and
 SQLCompiler.
 }}}

-- 
Ticket URL: 
Django 
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.7573e6c062bd15eb76abc0371b7ff5e0%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-07-05 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * ~~`BlockTranslateNode`~~ added in
> 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * ~~`BaseStorage`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`ChangeList`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`AdminForm`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`BlockContext`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`IncludeNode`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`Engine`~~ added in c609d5149c9295207cd7b2

Re: [Django] #24121: Provide a better repr() experience

2021-07-05 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"e4da3654367cd5f5c06ab109ece0042631faaa02" e4da3654]:
 {{{
 #!CommitTicketReference repository=""
 revision="e4da3654367cd5f5c06ab109ece0042631faaa02"
 Refs #24121 -- Added __repr__() to AdminSite, DefaultAdminSite, and
 ModelAdmin.

 Thanks tlebrize for the initial patch.
 }}}

-- 
Ticket URL: 
Django 
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.6c22756c96df76c567cd6b08553bc5ac%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-06-22 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * ~~`BlockTranslateNode`~~ added in
> 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * ~~`BaseStorage`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`ChangeList`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`AdminForm`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`BlockContext`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`IncludeNode`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`Engine`~~ added in c609d5149c9295207cd7b2

Re: [Django] #24121: Provide a better repr() experience

2021-06-22 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"bbb3965826c91406b94b819af7315ea1d39ec217" bbb39658]:
 {{{
 #!CommitTicketReference repository=""
 revision="bbb3965826c91406b94b819af7315ea1d39ec217"
 Refs #24121 -- Added __repr__() to StreamingHttpResponse and subclasses.
 }}}

-- 
Ticket URL: 
Django 
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.bc55ed9647693c8840334a3676fa6f54%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-06-17 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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 Nicolás Restrepo:

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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * ~~`BlockTranslateNode`~~ added in
> 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * ~~`BaseStorage`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`ChangeList`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`AdminForm`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`BlockContext`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`IncludeNode`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`Engine`~~ added in c609d5149c9295207cd7b2

Re: [Django] #24121: Provide a better repr() experience

2021-06-17 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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 Nicolás Restrepo:

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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * ~~`BlockTranslateNode`~~ added in
> 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * ~~`BaseStorage`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`ChangeList`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`AdminForm`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`BlockContext`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`IncludeNode`~~ added in 66ed03e7c9ae4cd754aa918c6f4c9227cf424141
> * ~~`Engine`~~ added in c609d5149c9295207cd7b2

Re: [Django] #24121: Provide a better repr() experience

2021-06-17 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  Nicolás Restrepo
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Nicolás Restrepo):

 add StreamingHttpResponse __repr()__ method =>
 https://github.com/django/django/pull/14531

-- 
Ticket URL: 
Django 
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.bf8b1ff034a985cf3f40468cbffeff3c%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-06-14 Thread Django

#24121: Provide a better repr() experience
--+---
 Reporter:  Keryn Knight  |Owner:  Nrestrepo05
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  dev
 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
--+---
Changes (by Nrestrepo05):

 * owner:  nobody => Nrestrepo05
 * status:  new => assigned


-- 
Ticket URL: 
Django 
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.5a38bd489f1114520683f3da7ff92648%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-06-10 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * ~~`BaseStorage`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * ~~`ChangeList`~~ added in 7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * ~~`Engine`~~ added in c609d5149c9295207cd7b2e8154e7b80a18d834a
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> If accepted, this ticket could just track whatever I can end up getting
> reviewed/merged, or it could be a meta-ticket for accep

Re: [Django] #24121: Provide a better repr() experience

2021-06-10 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"66ed03e7c9ae4cd754aa918c6f4c9227cf424141" 66ed03e]:
 {{{
 #!CommitTicketReference repository=""
 revision="66ed03e7c9ae4cd754aa918c6f4c9227cf424141"
 Refs #24121 -- Added __repr__() to AdminForm, BlockContext,
 BlockTranslateNode, and IncludeNode.
 }}}

-- 
Ticket URL: 
Django 
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.24e9747f1dcb84cdfc77ed881a7d932a%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-06-06 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92" 7dd502b]:
 {{{
 #!CommitTicketReference repository=""
 revision="7dd502b0e1e7d3e7fa2c5a2d54bbc926dbcf5f92"
 Refs #24121 -- Added __repr__() to ChangeList and BaseStorage.
 }}}

-- 
Ticket URL: 
Django 
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.45f08ca93dbab18bc9ee3768e54112cf%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-06-06 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * ~~`Engine`~~ added in c609d5149c9295207cd7b2e8154e7b80a18d834a
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-05-31 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine` [https://github.com/django/django/pull/14460 PR]
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-05-31 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"c609d5149c9295207cd7b2e8154e7b80a18d834a" c609d514]:
 {{{
 #!CommitTicketReference repository=""
 revision="c609d5149c9295207cd7b2e8154e7b80a18d834a"
 Refs #24121 -- Added __repr__() to Engine
 }}}

-- 
Ticket URL: 
Django 
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.940571a5f3574ba37bd3924da1a810b0%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-05-28 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * `PermWrapper`
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine` [https://github.com/django/django/pull/14460 PR]
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-05-28 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"22da686ca93e99f8091334f66d7199bc29b85c83" 22da686c]:
 {{{
 #!CommitTicketReference repository=""
 revision="22da686ca93e99f8091334f66d7199bc29b85c83"
 Refs #24121 -- Added __repr__() to PermWrapper.
 }}}

-- 
Ticket URL: 
Django 
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.e386dab3152153f5fba4320bfb971f65%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-05-27 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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 Abhyudai:

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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * `PermWrapper` [https://github.com/django/django/pull/14458 PR]
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine`
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-05-27 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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 Abhyudai:

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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * `PermWrapper`
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine`
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> 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

Re: [Django] #24121: Provide a better repr() experience

2021-05-24 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `Lookup` [https://github.com/django/django/pull/14111 PR]
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * `PermWrapper`
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine`
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> 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

Re: [Django] #24121: Provide a better repr() experience

2021-05-24 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"d3d95d645fc9f36355d27598475612de43587db1" d3d95d6]:
 {{{
 #!CommitTicketReference repository=""
 revision="d3d95d645fc9f36355d27598475612de43587db1"
 Refs #24121 -- Added __repr__() to Lookup.
 }}}

-- 
Ticket URL: 
Django 
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.05b3e1bfdad49bcb98de8e8b1b1223fb%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-05-24 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"f0a9413bd282cce452a5b7418b28b096af10a027" f0a9413b]:
 {{{
 #!CommitTicketReference repository=""
 revision="f0a9413bd282cce452a5b7418b28b096af10a027"
 Refs #24121 -- Improved Value.__repr__().
 }}}

-- 
Ticket URL: 
Django 
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.71e6dcdbfda272d3b6b8ebe7347f0188%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-05-23 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `Lookup` [https://github.com/django/django/pull/14111 PR]
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * `PermWrapper`
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite`
> * `ModelAdmin`
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine`
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-05-23 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `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`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite`
> * `ModelAdmin`
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine`
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> 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

Re: [Django] #24121: Provide a better repr() experience

2021-05-12 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `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`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite`
> * `ModelAdmin`
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine`
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> 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

Re: [Django] #24121: Provide a better repr() experience

2021-05-12 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"e6406853c326ea9210d07766138d2b193c6d1fba" e6406853]:
 {{{
 #!CommitTicketReference repository=""
 revision="e6406853c326ea9210d07766138d2b193c6d1fba"
 Refs #24121 -- Added__repr__() to StaticNode.
 }}}

-- 
Ticket URL: 
Django 
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.6bb76c9921f49fd3a05b576e7d683848%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-17 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `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`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite`
> * `ModelAdmin`
> * `Origin`
> * `Template`
> * `BlockContext`
> * `IncludeNode`
> * `Engine`
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> 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

Re: [Django] #24121: Provide a better repr() experience

2021-03-17 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"4f4f770f77c5d720484c0a71f6a19b9affcc7e28" 4f4f770]:
 {{{
 #!CommitTicketReference repository=""
 revision="4f4f770f77c5d720484c0a71f6a19b9affcc7e28"
 Refs #24121 -- Added __repr__() to Origin and Template.
 }}}

-- 
Ticket URL: 
Django 
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.47c6695b88a744b7106b82bd3dac7be5%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-16 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `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`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite`
> * `ModelAdmin`
> * `Origin`
> * `TemplateOrigin`
> * `BlockContext`
> * `IncludeNode`
> * `Template`/`Engine` (would need work still I think)
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-03-15 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by tiagohonorato):

 Added __repr__() to Origin [https://github.com/django/django/pull/14119]

-- 
Ticket URL: 
Django 
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.13131aaa1f7acd1b6c436865c7ace9f8%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-12 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Jonny Park):

 `Query` Does not have `__repr__` as well. Doesn't it need one?

-- 
Ticket URL: 
Django 
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.cdea8bcdcdfd3f0866676e499763ce40%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-11 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * `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`
> * `Response`
> * `SimpleTemplateResponse`
> * `TemplateResponse`
> * `AdminSite`
> * `ModelAdmin`
> * `Origin`
> * `TemplateOrigin`
> * `BlockContext`
> * `IncludeNode`
> * `Template`/`Engine` (would need work still I think)
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> 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

Re: [Django] #24121: Provide a better repr() experience

2021-03-11 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * `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`
> * `Response`
> * `SimpleTemplateResponse`
> * `TemplateResponse`
> * `AdminSite`
> * `ModelAdmin`
> * `Origin`
> * `TemplateOrigin`
> * `BlockContext`
> * `IncludeNode`
> * `Template`/`Engine` (would need work still I think)
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-03-10 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`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)
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

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

Re: [Django] #24121: Provide a better repr() experience

2021-03-10 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"dc86a25a677d05703e0bb021b178e44412cea7e9" dc86a25a]:
 {{{
 #!CommitTicketReference repository=""
 revision="dc86a25a677d05703e0bb021b178e44412cea7e9"
 Refs #24121 -- Added __repr__() to MiddlewareMixin and subclasses.
 }}}

-- 
Ticket URL: 
Django 
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.40674adeeb791e270beae201112094f5%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-10 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+
Changes (by Mariusz Felisiak):

 * has_patch:  1 => 0


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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`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.

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 -

Re: [Django] #24121: Provide a better repr() experience

2021-03-10 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by GitHub ):

 In [changeset:"afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d" afb0eb8]:
 {{{
 #!CommitTicketReference repository=""
 revision="afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d"
 Refs #24121 -- Added __repr__() to OrderedSet.
 }}}

-- 
Ticket URL: 
Django 
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.e7a4ded2aee73f40bab9757615f215b6%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-09 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Nick Pope):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14094 PR]

-- 
Ticket URL: 
Django 
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.a4f20d13424f9145d36cc7f6bb879f1b%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-02 Thread Django

#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
--+
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0


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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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.

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, #2

Re: [Django] #24121: Provide a better repr() experience

2021-03-02 Thread Django

#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:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"d3ecef26b9fda02b88f925a800ae38dd5873c878" d3ecef26]:
 {{{
 #!CommitTicketReference repository=""
 revision="d3ecef26b9fda02b88f925a800ae38dd5873c878"
 Refs #24121 -- Added __repr__() to URLNode.
 }}}

-- 
Ticket URL: 
Django 
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.454d9e826d5225cfcfd421a822e805bb%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-01 Thread Django

#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:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


-- 
Ticket URL: 
Django 
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.47f9d395315be5214a0760b43f6b9e6d%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-03-01 Thread Django

#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:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Rohith P R):

 * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
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.5e722ce2d06d9bdabb2762df6543ea7d%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-02-26 Thread Django

#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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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:
 {{{
 

 

 
 }}}
 All of which, IMHO, provide a more usef

Re: [Django] #24121: Provide a better repr() experience

2021-02-26 Thread Django

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

Comment (by Mariusz Felisiak ):

 In [changeset:"179ee13eb37348cd87169a198aec18fedccc8668" 179ee13]:
 {{{
 #!CommitTicketReference repository=""
 revision="179ee13eb37348cd87169a198aec18fedccc8668"
 Refs #24121 -- Added __repr__() to FilterExpression, Lexer, Parser, and
 Token.
 }}}

-- 
Ticket URL: 
Django 
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.af204b95bc54f5ff38e4952e51b4fa60%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-02-26 Thread Django

#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:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> 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 `` 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`
> * `HttpResponseNotAllowed`
> * `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:
 {{{
 

 

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

Re: [Django] #24121: Provide a better repr() experience

2021-02-25 Thread Django

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

Comment (by rohithpr):

 In [14045](https://github.com/django/django/pull/14045): Refs #24121 --
 Added repr to django.template.defaulttags.URLNode

-- 
Ticket URL: 
Django 
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.02a8e1542d825433a0a37968bb7af53d%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2021-02-12 Thread Django

#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
--+
Changes (by David Smith):

 * easy:  0 => 1


Comment:

 Marking as easy pickings as I think this can be achieved in stages -- I'm
 not expecting someone to propose a PR that addresses all of these in one
 go!

-- 
Ticket URL: 
Django 
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.77620728b773f9ff1aac598fc1418e09%40djangoproject.com.

Re: [Django] #24121: Provide a better repr() experience

2016-09-15 Thread Django

#24121: Provide a better repr() experience
--+
 Reporter:  kezabelle |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:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * component:  Uncategorized => Core (Other)


--
Ticket URL: 
Django 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.df3a7400b6fbe82f01ffa14914419adc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24121: Provide a better repr() experience

2015-08-31 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"d4b10a725614322769a419180039771634a06571" d4b10a72]:
 {{{
 #!CommitTicketReference repository=""
 revision="d4b10a725614322769a419180039771634a06571"
 Refs #24121 -- Added a repr() to gis.GeoIP and gis.GeoIP2.
 }}}

--
Ticket URL: 
Django 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.afa4cfffc108bba2f016e75864615e37%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24121: Provide a better repr() experience

2015-08-31 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"9c40f01a66bd15457e10a0bbf28c803968b5dabb" 9c40f01a]:
 {{{
 #!CommitTicketReference repository=""
 revision="9c40f01a66bd15457e10a0bbf28c803968b5dabb"
 Refs #24121 -- Added repr() to LazySettings, Settings, and
 UserSettingsHolder.
 }}}

--
Ticket URL: 
Django 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.144fbac4d84fc9ed3b94dc844b8a5c3b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24121: Provide a better repr() experience

2015-07-15 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"c96f11257baf43188ff9daeddab3221992925c85" c96f112]:
 {{{
 #!CommitTicketReference repository=""
 revision="c96f11257baf43188ff9daeddab3221992925c85"
 Refs #24121 -- Added meaningful repr() to HttpResponse and subclasses.
 }}}

--
Ticket URL: 
Django 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.be0a161c886ed153678f27be29d80e96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24121: Provide a better repr() experience

2015-01-11 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by berkerpeksag):

 > 
 >
 > 
 >
 > 

 `charset`, `name` and `loadname` should also be a string.

 {{{
 

 
 }}}

 Here's an example from Python:

 {{{
 >>> open('README')
 <_io.TextIOWrapper name='README' mode='r' encoding='UTF-8'>
 }}}

--
Ticket URL: 
Django 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.62342930e3ed3d3938cd7a6121071931%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24121: Provide a better repr() experience

2015-01-11 Thread Django

#24121: Provide a better repr() experience
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by jarshwah):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.20390ebd303994199b2bff502098c16e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

57 matches

Mail list logo