| msg95968 - (view) |
Author: Anthony Foglia (afoglia) |
Date: 2009-12-04 16:32 |
| It would be nice if pprint could format namedtuples wrapping lines as it does with tuples. Looking at the code, this does not look like an easy task. Completely rewriting pprint to allow it to be extensible to user-created classes would be best, but involve a ton of work. Simple making all named tuples derive from a named tuple base class (itself derived from tuple) would be simpler, albeit more of a hack. |
|
|
| msg95983 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2009-12-05 07:41 |
| I agree with you that pprint needs to be rewritten to make it more extensible. I do not see a straight-forward way of handling your feature request. First, namedtuple() is a factory function and is not itself a class, so there is no standard way to recognize one. Essentially, a named tuple is concept (any class that supported both sequence behavior and attribute access is a named tuple, for example the time structure is a named tuple but not created by the collections.namedtuple() factory function, instead is a C structseq which has substantially similar characteristics). This means that pprint has no reliable way to tell if one of its arguments is a named tuple. Second, collections.namedtuple() is intentionally designed to let the user override the default __repr__() method (see an example in the namedtuple docs). That means that pprint cannot know in advance how a named tuple is supposed to display. At best, I can imagine that pprint() grows the ability to print a multi-line repr (as specified by the object itself) but indented to a level controlled by pprint(). The pprint() function would scan the repr for newlines and replace them with a newline followed by the appropriate number of spaces. For example: >>> class Point(namedtuple('Point', 'x y z')): ... 'Point with a multi-line repr' ... def __repr__(self): ... return 'Point(\n x=%r,\n y=%r,\n z=%r\n )' % self >>> Point(3,4,5) Point( x=3, y=4, z=5 ) >>> pprint([Point(3,4,5), Point(6,7,8)]) [Point( x=3, y=4, z=5 ), Point( x=6, y=7, z=8 ) ] Alternatively, the pprint module could introduce a new magic method to support multi-line reprs when the repr itself it too long fit in a single line: class MyList(list): ... def __multirepr__(self): ... 'Return a list of strings to pprint' ... return Multi(head = 'Mylist([', ... body = [str(x).upper() for x in self], ... tail = ']) >>> pprint(MyList(['now', 'is', 'the', 'time', 'for']), width=15) MyList(['NOW', 'IS', 'THE', 'TIME', 'FOR', ]) In summary, there are several ways to approach this problem but they are centered on building-out pprint(), not on changing collections.namedtuple(). |
|
|
| msg96011 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-12-05 22:11 |
| You could make all namedtuples inherit from a common base class, e.g. `BaseNamedTuple`. |
|
|
| msg96014 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-12-06 01:15 |
| We need a more generic solution that allows multi-line reprs for a variety of types. Here is an example that doesn't involve named tuples: >>> pprint(s, width=15) [OrderedDict([('x', 30000000000), ('y', 4000000000), ('z', 5000000000)]), OrderedDict([('x', 6000000000), ('y', 70000000), ('z', 8000000000)])] What we want is to have it print like regular dictionaries do: >>> pprint([dict(p) for p in s], width=15) [{'x': 30000000000, 'y': 4000000000, 'z': 5000000000}, {'x': 6000000000, 'y': 70000000, 'z': 8000000000}] It would also be nice if pprint could accept arguments telling it how to format various types: >>> pprint(s, width=15, format={int: '15,'}) [{'x': ' 30,000,000,000', 'y': ' 4,000,000,000', 'z': ' 5,000,000,000'}, {'x': ' 6,000,000,000', 'y': ' 70,000,000', 'z': ' 8,000,000,000'}] |
|
|
| msg99530 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2010-02-18 21:29 |
| Sorry for the noise... |
|
|
| msg99534 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-02-18 21:53 |
| Will ponder this a bit more but will likely close this specific request (leaving open the possibility of a more general rewrite of pprint). |
|
|
| msg99554 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2010-02-19 03:32 |
| Could something like a generic __pprint__ hook achieve this? |
|
|
| msg118516 - (view) |
Author: Łukasz Langa (lukasz.langa) * |
Date: 2010-10-13 12:23 |
| I would like to work on that. Expect a patch soon. Georg, Fred, I've added you to nosy because you're the ones watching over me currently. Bare with me :) |
|
|
| msg122037 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-11-22 00:14 |
| Deferring the general rewrite until 3.3. It would need to have a lot of people look at it and evaluate it. I no longer think there is time for that before the 3.2 beta. |
|
|
| msg122968 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-12-01 01:13 |
| Attaching a rough concept of how to make the existing pprint module extendible without doing a total rewrite. The actual handler is currently bogus (no thought out), so focus on the @guard decorator and the technique for scanning for handlers. |
|
|
| msg138818 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2011-06-22 11:03 |
| Link to Armin's work on a pprint improvement based on a Ruby pprint tool: https://github.com/mitsuhiko/prettyprint |
|
|
| msg189750 - (view) |
Author: Łukasz Langa (lukasz.langa) * |
Date: 2013-05-21 13:18 |
| For the record, my class-based approach from 2010 still available here: https://bitbucket.org/ambv/nattyprint |
|
|
| msg207287 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2014-01-04 14:46 |
| With PEP 443 added for Python 3.4, I believe Łukasz intended to pursue a new pprint implementation based on functools.singledispatch. That has obviously missed feature freeze for Python 3.4, but it's still a reasonable idea to pursue for 3.5. In addition to OrderedDict (mentioned above) and defaultdict (which was mentioned in issue 5131), an updated pprint would also allow us to add support for the new dict view types, collections.deque, etc. Ideally, we'd also have a standard lazy import mechanism in 3.5, so these definitions could go in the collections module, but only installed if pprint was also imported. Otherwise, having pprint depend on collections would likely be preferable to having the dependency run the other way. |
|
|
| msg207299 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2014-01-04 18:28 |
| > Ideally, we'd also have a standard lazy import mechanism in 3.5, so these definitions could go in the collections module, but only installed if pprint was also imported. That sounds more like an on-import hook than a lazy import mechanism, no? |
|
|
| msg207300 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2014-01-04 18:28 |
| Oops... no, it's not easy. |
|
|
| msg207301 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2014-01-04 18:29 |
| Ok, so why did Roundup add the easy keyword and doesn't want to remove it? |
|
|
| msg218873 - (view) |
Author: Akira Li (akira) * |
Date: 2014-05-21 13:27 |
| Related issue #21542: pprint support for multiline collections.Counter |
|
|
| msg283212 - (view) |
Author: Louis Riviere (dugres) |
Date: 2016-12-14 18:53 |
| I've made a Pretty Printer and I'd like to know if anybody thinks it could of some help here. (I do) It's easily extensible and customizable to support any type in any way. https://github.com/louis-riviere-xyz/prettypy.git |
|
|