__repr__: to support pprint
Hi, everyone! Oftenly, __repr__ return "{type}({args}, {kws})" problem: 1) to call .format() myself is tedious I have seen someone do it wrong: "T(1,)"! I write a helper function myself, but to import such tiny function everywhere isnot good. 2) pprint cannot dive into string that from repr() To use pprint, I sometimes have to recursively turn objects into builtin containers: (type_name, args...) solution: allow __repr__ to return str OR tuple: (args, kws) Better, isn't it?
Yes, We are both python users with languages OTHER then English, It is a headache when looking at the print output of dicts with other language encoding. They are just byte array. I am using python2.7 Regards! At 2017-03-01 06:59:52, "语言破碎处" <mlet_it_bew@126.com> wrote: Hi, everyone! Oftenly, __repr__ return "{type}({args}, {kws})" problem: 1) to call .format() myself is tedious I have seen someone do it wrong: "T(1,)"! I write a helper function myself, but to import such tiny function everywhere isnot good. 2) pprint cannot dive into string that from repr() To use pprint, I sometimes have to recursively turn objects into builtin containers: (type_name, args...) solution: allow __repr__ to return str OR tuple: (args, kws) Better, isn't it?
Hi, On 1 March 2017 at 02:18, qhlonline <qhlonline@163.com> wrote:
Yes, We are both python users with languages OTHER then English, It is a headache when looking at the print output of dicts with other language encoding. They are just byte array. I am using python2.7
Please note that unless this is still a problem in python 3, this is unlikely to be changed. __repr__ is (as per the docs) 'a printable string representation of the object'. If this were to get changed, many APIs might be broken due to tuples not having the same methods and/or features as strings, e.g. you cannot use them as a path. Not saying that they will, but it's potentially breaking a lot of code which interacts with other programs, and maybe even some internals. You are free to experiment with overriding/extending __repr__ for your internal usage, but please note that it might break external libraries depending on obj.__repr__ or repr(obj), and print() might break when using built-in types as containers for your objects. I am a -1 on changing __repr__'s signature. -Matthias
On Wed, Mar 1, 2017 at 12:58 PM, Matthias welp <boekewurm@gmail.com> wrote:
You are free to experiment with overriding/extending __repr__ for your internal usage, but please note that it might break external libraries depending on obj.__repr__ or repr(obj), and print() might break when using built-in types as containers for your objects.
Given that this started out with a post about pprint, maybe a more viable approach would be a dedicated __pprint__ hook? That might be easier to push through. (I'm not pushing for it though.) ChrisA
On Wed, Mar 01, 2017 at 01:04:00PM +1100, Chris Angelico wrote:
On Wed, Mar 1, 2017 at 12:58 PM, Matthias welp <boekewurm@gmail.com> wrote:
You are free to experiment with overriding/extending __repr__ for your internal usage, but please note that it might break external libraries depending on obj.__repr__ or repr(obj), and print() might break when using built-in types as containers for your objects.
Given that this started out with a post about pprint, maybe a more viable approach would be a dedicated __pprint__ hook? That might be easier to push through. (I'm not pushing for it though.)
I like the idea of a __pprint__ dunder method in principle. But... what exactly is it supposed to do? In general, `self` cannot pretty-print itself, since it doesn't know if it is embedded inside another object, or whether the pretty-printer wants to constrain it to a certain width or number of lines. For example, if the printer wants to display a list using (say) three columns, aligned at the decimal points: [ 31.08713241722979, 983.3425750471824, -7234.474117265795, 0.7563959975516478, 21.08150956898832, 98.85759870687133, 219.76826846350912, -7.640051348488824, 0.5731518549129719, 32.961711789297816, 0.7563959975516478, 953487.1772710333 ] how would each float know how many leading spaces to use to align with the rest of the column? I don't think it could. Only the pretty printer itself would know how to align the float reprs, whether to truncate the displays, etc. It is possible that we could come up with a pretty-printing protocol, but that wouldn't be a trivial job. -- Steve
On 1 March 2017 at 13:50, Steven D'Aprano <steve@pearwood.info> wrote:
It is possible that we could come up with a pretty-printing protocol, but that wouldn't be a trivial job.
I'd be inclined to do this via simplegeneric. Let pprint do what it currently does, but allow users to register implementations for specific classes as they wish. I'm not sure how much work this would be - maybe a 3rd party "better pprint" module could prototype the approach to see if it's practical. Paul
On Mar 1, 2017, at 9:35 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 1 March 2017 at 13:50, Steven D'Aprano <steve@pearwood.info> wrote: It is possible that we could come up with a pretty-printing protocol, but that wouldn't be a trivial job.
I'd be inclined to do this via simplegeneric. Let pprint do what it currently does, but allow users to register implementations for specific classes as they wish.
If you mean functools.singledispatch, then I agree. It's even mentioned as a motivating case in PEP 443.
I'm not sure how much work this would be - maybe a 3rd party "better pprint" module could prototype the approach to see if it's practical. Paul
That seems reasonable. Eric.
On 01.03.17 16:35, Paul Moore wrote:
On 1 March 2017 at 13:50, Steven D'Aprano <steve@pearwood.info> wrote:
It is possible that we could come up with a pretty-printing protocol, but that wouldn't be a trivial job.
I'd be inclined to do this via simplegeneric. Let pprint do what it currently does, but allow users to register implementations for specific classes as they wish.
That is how pprint is implemented now. It register implementations for specific classes and dispatch them by type (or rather by __repr__ implementation). But these functions have too complex and non-extensible signatures and that is why this is an implementation detail. There is an open issue for a pretty-printing protocol, but it is far from any progress.
It has not to break current code: def repr(obj, allowed_tuple = False): r = type(obj).__repr__() if allowed_tuple: return r if isinstance(r, tuple): r = make_str(type(obj), r) return r At 2017-03-01 09:58:35, "Matthias welp" <boekewurm@gmail.com> wrote:
Hi,
On 1 March 2017 at 02:18, qhlonline <qhlonline@163.com> wrote:
Yes, We are both python users with languages OTHER then English, It is a headache when looking at the print output of dicts with other language encoding. They are just byte array. I am using python2.7
Please note that unless this is still a problem in python 3, this is unlikely to be changed.
__repr__ is (as per the docs) 'a printable string representation of the object'. If this were to get changed, many APIs might be broken due to tuples not having the same methods and/or features as strings, e.g. you cannot use them as a path. Not saying that they will, but it's potentially breaking a lot of code which interacts with other programs, and maybe even some internals.
You are free to experiment with overriding/extending __repr__ for your internal usage, but please note that it might break external libraries depending on obj.__repr__ or repr(obj), and print() might break when using built-in types as containers for your objects.
I am a -1 on changing __repr__'s signature.
-Matthias
participants (8)
-
Chris Angelico -
Eric V. Smith -
Matthias welp -
Paul Moore -
qhlonline -
Serhiy Storchaka -
Steven D'Aprano -
语言破碎处