Repository navigation
Need unit tests for <...> reprs #39747
Description
| BPO | 868845 |
|---|---|
| Nosy | @gvanrossum, @birkenfeld, @terryjreedy, @ncoghlan, @abalkin, @merwok, @akheron |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2011-10-18.16:10:54.968>
created_at = <Date 2004-01-01.16:28:37.000>
labels = ['easy', 'type-feature', 'tests']
title = 'Need unit tests for <...> reprs'
updated_at = <Date 2011-10-19.19:46:18.609>
user = 'https://github.com/gvanrossum'bugs.python.org fields:
activity = <Date 2011-10-19.19:46:18.609>
actor = 'eric.araujo'
assignee = 'none'
closed = True
closed_date = <Date 2011-10-18.16:10:54.968>
closer = 'gvanrossum'
components = ['Tests']
creation = <Date 2004-01-01.16:28:37.000>
creator = 'gvanrossum'
dependencies = []
files = ['9691']
hgrepos = []
issue_num = 868845
keywords = ['patch', 'easy']
message_count = 13.0
messages = ['60440', '60441', '60442', '63647', '63662', '63680', '64459', '113364', '145783', '145817', '145830', '145839', '145947']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'georg.brandl', 'terry.reedy', 'ncoghlan', 'belopolsky', 'eric.araujo', 'petri.lehtinen']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue868845'
versions = ['Python 3.2']
Activity
gvanrossum commentedon Jan 1, 2004
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?
ncoghlan commentedon Sep 27, 2004
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.
ncoghlan commentedon Sep 27, 2004
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
abalkin commentedon Mar 17, 2008
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.)
gvanrossum commentedon Mar 17, 2008
I'd rather not label this as easy yet, since there's a decision to be
made. I would welcome a doc patch though!
abalkin commentedon Mar 17, 2008
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.
birkenfeld commentedon Mar 25, 2008
Applied doc patch in r61871, r61872 (3.0).
terryjreedy commentedon Aug 9, 2010
Georg, did your two patches finish this issue, so it can be closed, or is there more to do?
akheron commentedon Oct 18, 2011
Ping? I wonder whether closing an issue from 2004 would result in "Achievement unlocked: archaeological issue management"
merwok commentedon Oct 18, 2011
Original report:
<...>-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:
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.
gvanrossum commentedon Oct 18, 2011
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.
merwok commentedon Oct 18, 2011
merwok commentedon Oct 19, 2011
I opened bpo-13224 with a patch to change str(class).