This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients belopolsky, eric.araujo, georg.brandl, gvanrossum, ncoghlan, petri.lehtinen, terry.reedy
Date 2011-10-18.16:10:54
SpamBayes Score 3.26822e-06
Marked as misclassified No
Message-id <>
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.
Date User Action Args
2011-10-18 16:10:55gvanrossumsetrecipients: + gvanrossum, georg.brandl, terry.reedy, ncoghlan, belopolsky, eric.araujo, petri.lehtinen
2011-10-18 16:10:55gvanrossumsetmessageid: <>
2011-10-18 16:10:54gvanrossumlinkissue868845 messages
2011-10-18 16:10:54gvanrossumcreate