[issue868845] Need unit tests for <...> reprs

[Éric Araujo]

Éric Araujo  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Éric Araujo]

Éric Araujo  added the comment:

> 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 .  (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.

--
stage: test needed -> committed/rejected

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Guido van Rossum]

Guido van Rossum  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 
.  (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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Éric Araujo]

Éric Araujo  added the comment:

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:




<__main__.foo object at 0x13fa810>

>


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.

--
nosy: +eric.araujo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Petri Lehtinen]

Petri Lehtinen  added the comment:

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

--
keywords: +patch
nosy: +petri.lehtinen

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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

--
nosy: +terry.reedy
versions: +Python 3.2 -Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Daniel Diniz]

Changes by Daniel Diniz :


--
components: +Tests -Library (Lib)
keywords: +easy -patch
stage:  -> test needed
type:  -> feature request
versions: +Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Applied doc patch in r61871, r61872 (3.0).

--
nosy: +georg.brandl


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

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.

--
keywords: +patch
Added file: http://bugs.python.org/file9691/doc-repr.diff


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Guido van Rossum]

Guido van Rossum <[EMAIL PROTECTED]> added the comment:

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


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue868845] Need unit tests for <...> reprs

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

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.)

--
nosy: +belopolsky


Tracker <[EMAIL PROTECTED]>


___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com