Guido van Rossum <[email protected]> added the comment:
I think there's nothing to be done for a bug this general.
If you find a specific object whose repr() is awkward, go ahead and file a
specific bug.
In most cases I think people who parse repr() output know they are on thin ice,
and would prefer that the object whose repr() they are parsing had a method or
attribute that returned what they were after. Example: in 3.2, parsing
repr(range(...)) is the only way to access the start/stop/step attributes; but
we're fixing this for 3.3. Exception: unittests that specifically verify the
form of a repr().
Off-topic: I sometimes wish that the str() of a class would return the class
name rather than its repr(); that way "print(str)" would print "str" instead of
<class 'str'>. (Use case: printing an exception and its message: I wish I
could print("%s: %s" % (err.__class__, err)) instead of having to use
err.__class__.__name__.) One could even claim that the repr() of a class could
be the same, since one of the guiding principles for repr() is that it should,
if possible, return an expression that (perhaps given a suitable environment)
could reconstruct the value exactly (and otherwise it should have the <...>
form discussed in this issue). But both of these wishes are debatable, and if
anyone cares, they should open a new bug to discuss it.
----------
resolution: -> works for me
status: open -> closed
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue868845>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
