[Tim]
Looks like Jim's suggested
from zope.testing.doctestunit import pprint
inherits this insecurity.
[Jim]
No, it doesn't.
from zope.testing.doctestunit import pprint pprint({"z": 1, "m": 2}) {'m': 2, 'z': 1}
Note both the sorting and the wrapping.
< See below. Cool! I confess that the 'width' fiddling in: def pprint(ob, **opts): if 'width' not in opts: opts['width'] = 1 return PrettyPrinter(**opts).pprint(ob) was incomprehensible to me just now -- you might want to add a comment to that ;-)
zope.doctestunit.pprint creates and uses a pretty printer with width set to 1, so all dicts are "long" and thus sorted.
Well, I understand why that works, but it's not part of pprint's contract either.
Note that, in Python 2.4, you can now pass a width to pprint without creating a separate pretty printer:
from pprint import pprint pprint({"z": 1, "m": 2}) {'z': 1, 'm': 2} pprint({"z": 1, "m": 2}, width=1) {'m': 2, 'z': 1}
So maybe we can phase out the use of docutestunit's pprint.)
Perhaps we should push to get the sorting behavior of pprint documented to allay your concerns.
I think it's harder than you yet realize: dicts don't require that keys be orderable, so pprint can't promise to sort dict displays. As-is, pprint simply blows up if, e.g., you pass it a "big dict" using complex numbers as keys. Could be nobody has noticed that yet, but since the trend in Python is to raise exceptions for non-equality comparisons of objects of different types, this kind of failure is bound to become more common. In the end, I wouldn't be surprised if pprint(dict) got changed to sort on the repr of the keys instead of on the keys themselves.
Better yet, perhaps we can get all dicts to be sorted.
As above.