Tim Peters wrote:
...
[Philipp]
Well, if you look closer you find that it uses pprint.pformat which
always outputs the
same on all machines (because it provides output sorted by the
dictionary key).
[Tres Seaver]
I see that in the implementation; it isn't documented as part of pprint's contract, however.
It's not part of the implementation either. For example,
d = {"z": 1, "m": 2} pprint.pprint(d)
{'z': 1, 'm': 2}
That is, it's not true that pprint always sorts a dict for display. Looks like Jim's suggested
from zope.testing.doctestunit import pprint
inherits this insecurity.
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.
In the example above, two things conspire to give "unsorted" output:
1. pprint(dict) doesn't try to sort at all if _repr(dict) is "short".
2. On my 32-bit box, hash('z') < hash('m'), which leads to platform accidents in dict insertion putting 'z' before 'm' in the "natural" dict iteration order:
d
{'z': 1, 'm': 2}
Because of #1, pprint passes on that order.
On a 64-bit box, the order may differ (or across Python versions on one box if the string hash, or dict insertion, algorithms change).
zope.doctestunit.pprint creates and uses a pretty printer with width set to 1, so all dicts are "long" and thus sorted. 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. Better yet, perhaps we can get all dicts to be sorted. 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