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