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

[Mahmoud Hashemi]

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.

Mahmoud


On Wed, Feb 10, 2016 at 11:18 AM, Michael Selik <mike at selik.org> wrote:

> The appropriate truncation for any repr that is too long would depend on
> the particulars of both the object and the purpose of the output. If
> reprlib and pprint were improved for say, defaultdict and OrderedDict, or
> more generic things, what would its features be?
>
> I'm guessing you wouldn't just duplicate the functionality of
> ``pprint(dict(x))``.
>
> On Tue, Feb 9, 2016, 4:09 AM Mahmoud Hashemi <mahmoud at hatnote.com> wrote:
>
>> If you want to make the case that default reprs should be
>> non-roundtrippable in the case that they're too long, that's a fine and
>> separate discussion. Though I have argued in the past that float('nan')
>> would be a less surprising/more useful repr.
>>
>> And that's what it's about, usefulness. It's useful to be able to copy in
>> and out of the REPL, even for very large reprs. I've done it, my coworkers
>> and students do it, and you've probably done it as well.
>>
>> But there are other times (often outside the REPL), where that is not the
>> case, and being able to address them explicitly, in the vein of reprlib and
>> pprint -- but better -- would be *useful*. Who hasn't wished that the
>> built-in defaultdict and OrderedDict were as pprintable or
>> reprlib.repr-able as dict.
>>
>> There's plenty of room to improve.
>>
>> On Tue, Feb 9, 2016 at 12:56 AM, Cory Benfield <cory at lukasa.co.uk> wrote:
>>
>>>
>>> > On 9 Feb 2016, at 02:49, Mahmoud Hashemi <mahmoud at hatnote.com> wrote:
>>> >
>>> > Roundtrippable reprs are certainly part of Python canon, whether or
>>> not they are universally used (Chris), or guaranteed (Mike).
>>> >
>>>
>>> They can be part of the canon all they want, but if they’re not
>>> universally guaranteed then I don’t know that this is a real problem. It
>>> means that the world of Python objects divides into two kinds: first, those
>>> with __repr__ return values that can be round tripped and those with
>>> __repr__ return values that cannot be round tripped.
>>>
>>> Given that objects of the second type already exist (I know this for a
>>> fact because I have written some quite recently!), it would be an error to
>>> assume that the identity 'eval(repr(x)) == x’ holds for arbitrary types. In
>>> fact, not only does it not hold for all third-party types, it doesn’t even
>>> hold for all built-in types:
>>>
>>> >>> x = float(‘nan’)
>>> >>> repr(x)
>>> ‘nan’
>>> >>> eval(repr(x))
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "<string>", line 1, in <module>
>>> NameError: name 'nan' is not defined
>>>
>>> I think the reality is that there is no constraint on the representation
>>> of arbitrary types to be round-trippable in any way. Again, all custom
>>> types have non-round-trippable representations by default, many more
>>> eclectic built-in types have non-round-tripppable representations (in
>>> addition to NaN, the memoryview object leaps to mind).
>>>
>>> I can also note the Python documentation on repr:
>>>
>>> > For many types, this function makes an attempt to return a string that
>>> would yield an object with the same value when passed to eval(), otherwise
>>> the representation is a string enclosed in angle brackets that contains the
>>> name of the type of the object together with additional information often
>>> including the name and address of the object.
>>>
>>> If the language doesn’t even try to enforce the idea that
>>> representations will be round-trippable, I think there’s just no problem
>>> here.
>>>
>>> Cory
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160210/c2a69af8/attachment-0001.html>