homepage

Samuele Pedroni points out in python-dev that the <...>
style reprs of Python objects are not documented,
standardized or even consistent (e.g. compare old-style
and new-style classes).
Yet there is plenty of code out there that for various
reasons parses these things or a least depends on what
they look like (the parrot benchmark being only the
latest example).
So it would behoove us to standardize these. An easy
way would be unit tests. Any takers?

Logged In: YES 
user_id=1038590
Sure. I've been looking for something to do after giving up
on finding any more Python-level speed increases for Decimal :)
Patch forthcoming in the next few days.

Logged In: YES 
user_id=1038590
Although, now that I look at the relevant py-dev threads,
I'm not entirely sure what needs to be standardised.
Consider the following:
<type 'array.array'>
<type 'dict'>
__main__.foo
<__main__.foo instance at 0xf6f8baac>
<unbound method foo.x>
<bound method foo.x of <__main__.foo instance at 0xf6f8bacc>>
<class '__main__.bar'>
<__main__.bar object at 0xf6f8baec>
<unbound method bar.x>
<bound method bar.x of <__main__.bar object at 0xf6f8bb0c>>
<function func at 0xf6f87294>
Which is the result of:
from array import array
class foo:
 def x(): pass
 
class bar(object):
 def x(): pass
def func(): pass
for obj in array, dict, foo, foo(), foo.x, foo().x, bar,
bar(), bar.x, bar().x, func:
 print obj

If any work needs to be done on this issue, it should probably be 
labeled "easy." (At least the writing the unit tests part. Making 
<...> reprs consistent is another story.)
The unit tests for old-style and new-style class reprs are present in 
test_repr and seem to predate the original request.
There are some more similar tests elsewhere (test_file, test_descr, 
etc.)

I'd rather not label this as easy yet, since there's a decision to be
made. I would welcome a doc patch though!

I think the attached patch captures the most of what can currently be 
said about <...> reprs.
I think the biggest offender in terms of inconsistency in the 2.x series 
is the file object with the repr which does not even start with the name 
of the type.
For 3.0, I think it is feasible to standardize on the <{type} object 
['{name}'] ... at 0x{addr}> pattern.

Applied doc patch in r61871, r61872 (3.0).

Georg, did your two patches finish this issue, so it can be closed, or is there more to do?

Ping? I wonder whether closing an issue from 2004 would result in "Achievement unlocked: archaeological issue management"

Original report:
> Samuele Pedroni points out in python-dev that the <...> style reprs of Python objects are
> not documented, standardized or even consistent (e.g. compare old-style and new-style
> classes).
>
> Yet there is plenty of code out there that for various reasons parses these things or a
> least depends on what they look like (the parrot benchmark being only the latest example).
<...>-style reprs have been documented by Georg; for the consistency part, I just run the snippet from Nick on 3.2:
<class 'array.array'>
<class 'dict'>
<class '__main__.foo'>
<__main__.foo object at 0x13fa810>
<function x at 0x1399050>
<bound method foo.x of <__main__.foo object at 0x13fa850>>
<function func at 0x132cf30>
I would call that consistent. (FWIW I like that the dict repr contains "dict" and not "builtins.dict", as the common form for using it does not need the module part.)
For the standardization part, Alexander proposed this:
> For 3.0, I think it is feasible to standardize on the
> <{type} object ['{name}'] ... at 0x{addr}> pattern.
If there are tools out there that parse reprs, I think a change that would break them should have been in 3.0, now we’re bound by b/w compat.
To sum up: <...>-style reprs are documented and consistent enough, so let’s close this.

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.

> 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__.)
Me too. I have a small metaclass to do that :) Given your tentative support, I’ll open a feature request for 3.3.
> One could even claim that the repr() of a class could be the same
I think of repr first as "string form for debugging", so I like the angle brackets.

I opened #13224 with a patch to change str(class).