[Zope-dev] Re: Unit Test Failures

[Tim Peters]

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