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

Mahmoud Hashemi mahmoud at hatnote.com
Tue Feb 9 04:09:04 EST 2016


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/20160209/579073b8/attachment-0001.html>


More information about the Python-ideas mailing list