[Zope-dev] Re: Unit Test Failures

[Jim Fulton]

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 at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org