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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to