I noticed this the other day when debugging a program that neither set()
nor defaultdict() pprint() properly

Same under 3.1 and 2.5 (Not tried 2.6/2.7 but I assume it is the same)

>>> pprint(set(range(100)))
set([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54,
55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72,
73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90,
91, 92, 93, 94, 95, 96, 97, 98, 99])

>>> from collections import defaultdict
>>> pprint(defaultdict(int).fromkeys(range(100)))
defaultdict(None, {0: None, 1: None, 2: None, 3: None, 4: None, 5: None,
6: None, 7: None, 8: None, 9: None, 10: None, 11: None, 12: None, 13:
None, 14: None, 15: None, 16: None, 17: None, 18: None, 19: None, 20:
None, 21: None, 22: None, 23: None, 24: None, 25: None, 26: None, 27:
None, 28: None, 29: None, 30: None, 31: None, 32: None, 33: None, 34:
None, 35: None, 36: None, 37: None, 38: None, 39: None, 40: None, 41:
None, 42: None, 43: None, 44: None, 45: None, 46: None, 47: None, 48:
None, 49: None, 50: None, 51: None, 52: None, 53: None, 54: None, 55:
None, 56: None, 57: None, 58: None, 59: None, 60: None, 61: None, 62:
None, 63: None, 64: None, 65: None, 66: None, 67: None, 68: None, 69:
None, 70: None, 71: None, 72: None, 73: None, 74: None, 75: None, 76:
None, 77: None, 78: None, 79: None, 80: None, 81: None, 82: None, 83:
None, 84: None, 85: None, 86: None, 87: None, 88: None, 89: None, 90:
None, 91: None, 92: None, 93: None, 94: None, 95: None, 96: None, 97:
None, 98: None, 99: None})
>>>

sets and frozensets have already been updated to format like lists.
This patch formats defaultdicts like dicts.

I couldn't actually get this patch to apply to the py3k branch :-(

$ patch -p0 --dry-run < issue_5131.patch
patching file Misc/NEWS
Hunk #1 FAILED at 2598.
1 out of 1 hunk FAILED -- saving rejects to file Misc/NEWS.rej
patching file Misc/ACKS
Hunk #1 succeeded at 147 (offset -1 lines).
Hunk #2 succeeded at 791 (offset 3 lines).
patching file Lib/pprint.py
Hunk #1 FAILED at 37.
Hunk #2 FAILED at 137.
Hunk #3 FAILED at 168.
3 out of 3 hunks FAILED -- saving rejects to file Lib/pprint.py.rej
patching file Lib/test/test_pprint.py
Hunk #1 succeeded at 408 (offset -6 lines).

$ svn info
Path: .
URL: http://svn.python.org/projects/python/branches/py3k
Repository Root: http://svn.python.org/projects
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 70705
Node Kind: directory
Schedule: normal
Last Changed Author: antoine.pitrou
Last Changed Rev: 70696
Last Changed Date: 2009-03-29 20:30:55 +0100 (Sun, 29 Mar 2009)

py3k is different enough (esp the NEWS) that I'll have to apply it by
hand. This patch was against the 2.x trunk.

Oops, my bad, I assumed the patch would by for py3k!

I applied it to trunk and tested it. It works very well - thank you for
fixing that :-)

I removed 'a set or' from the title since sets are no longer an issue.

Since .fromkeys is a class method, it should be called on a class rather than an instance. I was initially fooled by the irrelevant addition of '(int)'. 100 is unnecessarily large for example and review.

Patch changes code and test. However, I cannot tell what effect is has merely from reading the patch. Please add an example of the altered output, with 100 lowered to 5 or 10.

A doc change is not needed since it merely says "The pprint module provides a capability to “pretty-print” arbitrary Python data structures "

I suspect the patch needs some update to apply to for 3.2a. Has Tarek's name been fixed already?

Patch looks good to me.
(Some day the pprint module should grow some way to register repr for user types, so we can stop adding special cases; but defaultdict() is a builtin)

Jack, can you update your patch to reflect Terry’s review?

Amaury, have you opened a feature request about your registration idea?

BTW, Tarek’s name is valid UTF-8 in py3k.

Same applies to collections.deque, which seems closely related (being another collections class). Can this get addressed here or should I open another issue?

(just been pprinting defaultdict(deque) objects, which clearly fails :)

Ben, I don't think there is any value is opening more issues like pprint-doesn't-handle-object-x (named tuples, defautdicts, deques, generators, etc).

As it is currently designed, pprint doesn't offer usable hooks and it is not easy to build-out to handle new object types. For the most part, users just cast to a list before calling pprint.

ISTM, the RightAnswer(tm) is to overhaul pprint and add hooks for handling new objects. Ideally, there would be flexible print options and reprlib-like features for limiting output and for marking recursive constructs with "..."

It would be better to start fresh than to continually pile on to the current hodge-podge.

Raymond Hettinger (rhettinger) wrote:

Ben, I don't think there is any value is opening more issues like pprint-doesn't-handle-object-x (named tuples, defautdicts, deques, generators, etc).

As it is currently designed, pprint doesn't offer usable hooks and it is not easy to build-out to handle new object types. For the most part, users just cast to a list before calling pprint.

I mildly disagree, IMHO pprint should be able to make a decent job of all the built in types otherwise it loses its value as a debugging tool. It is a suprise when a built in type doesn't pprint properly.

This would surely be an excellent use of the abstract base classes defined in the collections module for pprint to make a best guess as to how to print types it doesn't understand directly?

ISTM, the RightAnswer(tm) is to overhaul pprint and add hooks for handling new objects. Ideally, there would be flexible print options and reprlib-like features for limiting output and for marking recursive constructs with "..."

That is a very good idea, but might be unecessary with the ABC idea above

IMHO pprint should be able to make a decent job of all the built in types

Agreed, already true as far as I know, and irrelevant. This issue is not about built-in types in the builtins module, as documented Lib Ref chapter 5 *Built-in Types*. Collections is an Python-coded stdlib module that happens to import a couple of its classes from _collections, written in C for speed.

I agree with Raymond that pprint needs a generic solution better than special-casing one class after another. Your idea of using ABCs intriguing.

Terry J. Reedy (terry.reedy) wrote:

> IMHO pprint should be able to make a decent job of all the built in types

Agreed, already true as far as I know, and irrelevant. This issue is not about built-in types in the builtins module, as documented Lib Ref chapter 5 *Built-in Types*. Collections is an Python-coded stdlib module that happens to import a couple of its classes from _collections, written in C for speed.

My bad - not precise enough! I meant all the stdlib types rather than the builtin types.

Closing this as a duplicate of bpo-7434 (which is about redesigning pprint to make it easier to add support for new types)