| msg60440 - (view) |
Author: Guido van Rossum (gvanrossum) *  |
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: Alyssa Coghlan (ncoghlan) * |
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: Alyssa Coghlan (ncoghlan) * |
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> <bound method foo.x of <__main__.foo instance at 0xf6f8bacc>> <class '__main__.bar'> <__main__.bar object at 0xf6f8baec> <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) * |
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) * |
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) * |
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) * |
Date: 2008-03-25 07:22 |
| Applied doc patch in r61871, r61872 (3.0). |
|
|
| msg113364 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2011-10-19 19:46 |
| I opened #13224 with a patch to change str(class). |
|
|