[Python-ideas] Compact repr operator (i.e., __short_repr__)

[Mahmoud Hashemi]

Michael: Yes, I have several projects on PyPI, some of which are related
and somewhat popular, but I hardly think that a PyPI package can encompass
the API changes I'm describing. We already have several built-in modules
(reprlib, pprint) and 3rd party modules (IPython Notebook, Django 500
pages, the Werkzeug debugger) that see a great deal of usage, but only
support a few builtinn types and have to hack heuristics for the rest.

Cory: Introspecting application state happens at many levels, one step at a
time. Not only is perfect the enemy of good here, but I really don't think
an omni-solution like the one you're describing is a realistic, Pythonic
goal. Besides, graphs are powerful, but don't go underestimating linear
text.

An enhanced repr allows developer-users to communicate the context of their
usage so that the library authors can programmatically provide and
prioritize information in their types. I've seen (and written) plenty of
reprs that encode useful information in my types. To your example, I might
have: <MyLock 0x123 held=True>.

I still think you're selling repr short. It can be much more. One day we
might have:

>>> repr(obj, pretty=True, depth=2, width=120)

Though, as I said before, my primary use case isn't the REPL, and those
arguments should be part of the REPL config (pprint defaults to width=80
for consoles). The point is that repr has room to evolve.

Mahmoud

On Thu, Feb 11, 2016 at 1:00 AM, Cory Benfield <cory at lukasa.co.uk> wrote:

>
> > On 10 Feb 2016, at 19:31, Mahmoud Hashemi <mahmoud at hatnote.com> wrote:
> >
> > For those examples, the pprint/reprlib behavior probably wouldn't be
> much different than dict/list of tuples. I can put my vote in, but I prefer
> to defer design specifics to the creators/maintainers of those types.
> That's my point.
> >
> > Right now I feel like repr() is a powerful, but underleveraged function
> in the builtin ecosystem. Instead of pprint.pformat(), why not add a
> keyword argument, and have repr(obj, pretty=True), and have that call
> through with arguments to a more full featured __repr__? Same could go for
> repr(obj, length=150, depth=2). These could have defaults set for REPL
> sessions.
> >
> > Everyone is doing hacky, incomplete heuristic introspection, from
> IPython to the standard library. Instead, let's embrace the complexities of
> viewing application state, and allow for formalization of community efforts.
>
> If we want to embrace the complexities of viewing application state,
> perhaps we should divorce this conversation from the repr altogether.
>
> There’s plenty of applications where “viewing application state” will
> require more than the repr generally provides: you’ll want insight into
> private member variables, into the state of composed objects, and
> potentially into the state of some of those private member variables (e.g.
> is this lock held at this moment?). This is outside the generally accepted
> scope of the repr as I understand it: most people don’t provide the repr in
> this form.
>
> If you want the complexity of application state then you probably want
> some way to dump the graph of objects starting with a specific one, along
> with their state. That’s totally beyond the scope of the repr, and is
> closer to what pickle would do for you (though as Andrew points out, pickle
> is not the right tool for this job either).
>
> What I don’t understand is: if you are in the REPL already, what does any
> of this buy you? The REPL has plenty of powerful tools for introspecting
> Python objects: specifically, it has the Python programming language! If
> you want to introspect application state from the REPL, then just grab the
> object you want and start interrogating its state. dir() works, printing
> fields works, calling methods works, and all of this is far more powerful
> than anything you can get from the repr.
>
> Cory
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160211/7ceabd2b/attachment.html>