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.

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().

You could make all namedtuples inherit from a common base class, e.g.
`BaseNamedTuple`.

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'}]

Sorry for the noise...

Will ponder this a bit more but will likely close this specific request (leaving open the possibility of a more general rewrite of pprint).

Could something like a generic __pprint__ hook achieve this?

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 :)

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.

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.

Link to Armin's work on a pprint improvement based on a Ruby pprint tool:  https://github.com/mitsuhiko/prettyprint

For the record, my class-based approach from 2010 still available here:

https://bitbucket.org/ambv/nattyprint

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.

> 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?

Oops... no, it's not easy.

Ok, so why did Roundup add the easy keyword and doesn't want to remove it?

Related issue #21542: pprint support for multiline collections.Counter

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