Tim Peters wrote: ...
Well, I understand why that works, but it's not part of pprint's contract either.
What contract. :) Aren't you always telling me to read the source?
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.
That's fine. In practice, when we do this sort of thing, the keys are almost always strings.
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.
That wouldn't be bad. Anyway, I guess we should make an issue of this on python-dev, so that either we can count on documented behavior going forward or so that we write our pwn pretty printer for use in doctest. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org