[Zope-dev] Re: Unit Test Failures

[Tim Peters]

...

[Tim]
>> Well, I understand why that works, but it's not part of pprint's
>> contract either.

[Jim]
> What contract. :)

pprint's docs.

> Aren't you always telling me to read the source?

Indeed, if you hadn't, you wouldn't have known that forcing width=1
forces dict sorting ;-)  It's common as mud to close a bug report in
Pythonland too when it's just griping about changes in undocumented
behavior.

...

>> 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.

My point is that you're relying on undocumented behavior now, and so
there's no guarantee it will continue to behave that way.  To the
contrary, because sorting dicts _started_ creating problems when
Python gave up its original "any pair of objects can be compared"
behavior, and Python continues moving away from that, there's reason
to worry that pprint may give up sorting dict displays entirely. 
Sorting isn't free, is currently a source of bugs in pprint, and adds
a large memory burden (to materialize a giant dict.items() list) when
pprint'ing a large dict.  An obvious alternative is for pprint to
change to do dict.iteritems() when building a display, which is much
better on all those counts.

If I have anything to say about it, it will continue to sort, but
nobody listens to me anymore ;-)

>> 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.

It's debatable for sure.

> 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.

I'll try to make time for this next week (I'm on vacation then).