[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