A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-January/085640.html below:

[Python-Dev] pprint(iterator)

[Python-Dev] pprint(iterator)Michael Foord fuzzyman at voidspace.org.uk
Thu Jan 29 15:22:47 CET 2009
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())
>>     
>
> Along the lines of what others have said: pprint() cannot consume an
> unknown iterator.  Therefore, you can pretty up the existing output
> slightly or special-case certain known iterators.  There might also be an
> API change to pprint() that allowed it to consume iterators.
>
> 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.)
>
> This can also be done for Python 2.7, too.
>   
Don't we have a pretty-print API - and isn't it spelled __str__ ?

Michael Foord

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


More information about the Python-Dev mailing list

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