On Thu, Jan 29, 2009, Michael Foord wrote: > Aahz wrote: >> On Tue, Jan 27, 2009, Raymond Hettinger wrote: >> >>> It is becoming the norm in 3.x for functions to return iterators, >>> generators, or views whereever possible. >>> >>> I had a thought that pprint() ought to be taught to print iterators: >>> >>> pprint(enumerate(seq)) >>> pprint(map(somefunc, somedata)) >>> pprint(permutations(elements)) >>> pprint(mydict.items()) >>> >> >> The reason I'm chiming in is that I would welcome a PEP that created a >> __pprint__ method as an alternative to special-casing. I think that it >> would be generically useful for user-created objects, plus once you've >> added this feature other people can easily do some of the grunt work of >> extending this through the Python core. (Actually, unless someone >> objects, I don't think a PEP is required, but it would be good for the >> usual reasons that PEPs are written, to provide a central place >> documenting the addition.) > > Don't we have a pretty-print API - and isn't it spelled __str__ ? In theory, yes. In practice, we wouldn't be having this discussion if that really worked. But it probably would make sense to see how far using __str__ can take us -- AFAICT enumobject.c doesn't define __str__ (although I may be missing something, I don't know Python at the C level very well). -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4