msg60440 - (view) |
Author: Guido van Rossum (gvanrossum) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2004-01-01 16:28 |
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?
|
msg60441 - (view) |
Author: Nick Coghlan (ncoghlan) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2004-09-27 09:58 |
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.
|
msg60442 - (view) |
Author: Nick Coghlan (ncoghlan) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2004-09-27 11:23 |
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
|
msg63647 - (view) |
Author: Alexander Belopolsky (belopolsky) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2008-03-17 15:06 |
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.)
|
msg63662 - (view) |
Author: Guido van Rossum (gvanrossum) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2008-03-17 16:13 |
I'd rather not label this as easy yet, since there's a decision to be
made. I would welcome a doc patch though!
|
msg63680 - (view) |
Author: Alexander Belopolsky (belopolsky) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2008-03-17 17:19 |
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.
|
msg64459 - (view) |
Author: Georg Brandl (georg.brandl) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2008-03-25 07:22 |
Applied doc patch in r61871, r61872 (3.0).
|
msg113364 - (view) |
Author: Terry J. Reedy (terry.reedy) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2010-08-09 03:21 |
Georg, did your two patches finish this issue, so it can be closed, or is there more to do?
|
msg145783 - (view) |
Author: Petri Lehtinen (petri.lehtinen) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-10-18 08:40 |
Ping? I wonder whether closing an issue from 2004 would result in "Achievement unlocked: archaeological issue management"
|
msg145817 - (view) |
Author: Éric Araujo (eric.araujo) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-10-18 15:45 |
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.
|
msg145830 - (view) |
Author: Guido van Rossum (gvanrossum) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-10-18 16:10 |
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.
|
msg145839 - (view) |
Author: Éric Araujo (eric.araujo) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-10-18 16:40 |
> 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.
|
msg145947 - (view) |
Author: Éric Araujo (eric.araujo) * ![Python committer (Python committer)](@@file/committer.png) |
Date: 2011-10-19 19:46 |
I opened #13224 with a patch to change str(class).
|
|
Date |
User |
Action |
Args |
2022-04-11 14:56:01 | admin | set | github: 39747 |
2011-10-19 19:46:18 | eric.araujo | set | messages:
+ msg145947 |
2011-10-18 16:40:39 | eric.araujo | set | messages:
+ msg145839 stage: test needed -> resolved |
2011-10-18 16:10:54 | gvanrossum | set | status: open -> closed resolution: works for me messages:
+ msg145830
|
2011-10-18 15:45:16 | eric.araujo | set | nosy:
+ eric.araujo messages:
+ msg145817
|
2011-10-18 08:40:32 | petri.lehtinen | set | keywords:
+ patch nosy:
+ petri.lehtinen messages:
+ msg145783
|
2010-08-09 03:21:30 | terry.reedy | set | nosy:
+ terry.reedy
messages:
+ msg113364 versions:
+ Python 3.2, - Python 3.1, Python 2.7 |
2009-02-14 12:08:59 | ajaksu2 | set | keywords:
+ easy, - patch versions:
+ Python 3.1, Python 2.7 type: enhancement components:
+ Tests, - Library (Lib) stage: test needed |
2008-03-25 07:22:38 | georg.brandl | set | nosy:
+ georg.brandl messages:
+ msg64459 |
2008-03-17 17:19:26 | belopolsky | set | files:
+ doc-repr.diff keywords:
+ patch messages:
+ msg63680 |
2008-03-17 16:13:01 | gvanrossum | set | messages:
+ msg63662 |
2008-03-17 15:06:20 | belopolsky | set | nosy:
+ belopolsky messages:
+ msg63647 |
2004-01-01 16:28:37 | gvanrossum | create | |