[Python-Dev] pprint(iterator)

Ron Adam rrr at ronadam.com
Fri Jan 30 04:23:55 CET 2009



Steven D'Aprano wrote:
> Michael Foord wrote:
> 
>> Don't we have a pretty-print API - and isn't it spelled __str__ ?
> 
> Not really. If it were as simple as calling str(obj), there would be no 
> need for the pprint module.

I agree.  And when I want to use pprint, there are usually additional 
output formatting requirements I need that isn't a "one size fits all" type 
of problem.


In any case, it seems that the pprint module
> actually calls repr() on objects other than dicts, tuples and lists.
> 
> I'm concerned about the number of special methods exploding, but I've 
> also come across times where I needed more than two string 
> representations of an object. Sometimes I solved this by adding a 
> pprint() method, other times I used other names, and it would be nice if 
> there was a standard way of spelling it. So I'm +0.5 on Aahz's 
> suggestion of __pprint__.

I'm -.5 on addint __pprint__ for the above reasons.


> In my ideal world, __pprint__ should allow (but not require) extra 
> arguments, so that one can do something like the following:
>
> pprint(binarytree)  # sensible defaults
> pprint(binarytree, order='preorder')

It seems to me pprint is one of those functions where output format 
specifiers and keywords make sense because you are trying to fit the data 
output of a wide variety of types to a particular output need.  It's not 
reasonably possible for each type to predict what that output need is.

Some of the options that sound useful might be:

    abbreviated form
    short form
    long complete detail form
    tree form
    column align form
    right or left margins and alignment options

Think of it as how 'dir' is used for examining the contents of a disk drive 
where different output styles is useful at different times.

Looking at it this way, instead of a __pprint__ method, a optional 
__pprint_style__ attribute could specify a default output style that the 
pprint function would fall back to.


Maybe for iterators, it's not the data produced but rather the current 
state of use that is more useful?

For example for partially consumed iterators it might be useful to express 
how many items have been taken, and how many are left to take when that 
info is available. (?)

The idea is that pretty printing is usually used to check the status or 
state of something.  Or at least that is how I use it.

Ron



















More information about the Python-Dev mailing list