From wrobell at pld-linux.org  Fri Aug 10 21:50:49 2007
From: wrobell at pld-linux.org (wrobell)
Date: Fri, 10 Aug 2007 20:50:49 +0100
Subject: [Python-ideas] pprint in python 3000
Message-ID: <20070810195049.GK17274@borg>

hi,

sometimes, when using print, i find pprint (pretty-print) module very
useful. but then one has to import pprint module and use completely
different function to dump structure to screen.

therefore i am wondering if it is possible to integrate pprint module
functionality on print level function (python 3000) with 'pretty'
parameter. of course, it opens some can of worms... but maybe it is worth
considering?


regards,

    wrobell <wrobell at pld-linux.org>


From brett at python.org  Sat Aug 11 01:18:05 2007
From: brett at python.org (Brett Cannon)
Date: Fri, 10 Aug 2007 16:18:05 -0700
Subject: [Python-ideas] pprint in python 3000
In-Reply-To: <20070810195049.GK17274@borg>
References: <20070810195049.GK17274@borg>
Message-ID: <bbaeab100708101618h477d0d2esb7765f6c526f0871@mail.gmail.com>

On 8/10/07, wrobell <wrobell at pld-linux.org> wrote:
> hi,
>
> sometimes, when using print, i find pprint (pretty-print) module very
> useful. but then one has to import pprint module and use completely
> different function to dump structure to screen.
>

But the import is minimal.  Plus with 'print' becoming a function you
could easily replace the built-in 'print' with a pretty-print
implementation application wide.

> therefore i am wondering if it is possible to integrate pprint module
> functionality on print level function (python 3000) with 'pretty'
> parameter. of course, it opens some can of worms... but maybe it is worth
> considering?

I have never felt the need for this, so I don't feel like opening the
can of worms.  =)

-Brett


From fdrake at acm.org  Sat Aug 11 01:53:11 2007
From: fdrake at acm.org (Fred Drake)
Date: Fri, 10 Aug 2007 19:53:11 -0400
Subject: [Python-ideas] pprint in python 3000
In-Reply-To: <bbaeab100708101618h477d0d2esb7765f6c526f0871@mail.gmail.com>
References: <20070810195049.GK17274@borg>
	<bbaeab100708101618h477d0d2esb7765f6c526f0871@mail.gmail.com>
Message-ID: <00A51D69-9F07-43D4-BA65-FAB581C424D4@acm.org>

On Aug 10, 2007, at 7:18 PM, Brett Cannon wrote:
> I have never felt the need for this, so I don't feel like opening the
> can of worms.  =)

What's more, "from pprint import pprint" takes care of most of the  
verbosity, so... I don't think there's a need to integrate it into  
the print() function either.

It might be reasonable to change the keyword args that pprint accepts  
to match those of the print() function, though.  They correspond like  
this:

   print()        pprint()
   -------------  -------------
   file           stream
   end            (none)
   sep            (none)
   (none)         depth
   (none)         indent
   (none)         width

I think it would be reasonable to either replace "stream" with  
"file" (or accept both), and add support for "end" to pprint().   
"sep" is irrelevant, since pprint() prints only one object.  The  
three pprint()-specific arguments aren't relevant to print().


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From adam at atlas.st  Sat Aug 11 02:14:28 2007
From: adam at atlas.st (Adam Atlas)
Date: Fri, 10 Aug 2007 20:14:28 -0400
Subject: [Python-ideas] pprint in python 3000
In-Reply-To: <20070810195049.GK17274@borg>
References: <20070810195049.GK17274@borg>
Message-ID: <60FB37A5-FB68-42D9-9D8A-42517BCE9003@atlas.st>

Perhaps `repr` instead could grow a `pretty` parameter, default  
False; if true, it could also take the `depth`, `indent`, and `width`  
parameters that `pformat` now takes.

It would act basically like `pformat` in that case. Normally it would  
do its best to pretty-format known data types, using __repr__  
otherwise, but perhaps objects could also override a __prettyrepr__  
method, always taking (object, indent, width, depth), and returning a  
pretty-formated string. This function could pass those parameters  
along recursively to repr(x, pretty=True, ...) again if it has child  
objects it needs to represent.


From tomerfiliba at gmail.com  Sun Aug 12 18:09:17 2007
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sun, 12 Aug 2007 16:09:17 -0000
Subject: [Python-ideas] pprint in python 3000
In-Reply-To: <60FB37A5-FB68-42D9-9D8A-42517BCE9003@atlas.st>
References: <20070810195049.GK17274@borg>
	<60FB37A5-FB68-42D9-9D8A-42517BCE9003@atlas.st>
Message-ID: <1186934957.407754.11390@r34g2000hsd.googlegroups.com>

On Aug 11, 2:14 am, Adam Atlas <a... at atlas.st> wrote:
> Perhaps `repr` instead could grow a `pretty` parameter, default
> False; if true, it could also take the `depth`, `indent`, and `width`
> parameters that `pformat` now takes.

that would only lead to endless bloat. once you start bloating
one part of the core, there's no reason not to bloat the others,
and pretty soon you'll end up with perl 6. besides, how can you
tell how does one wish to format his output?

the core must remain lean, providing only the bare functionality.
customizations should be added through stdlib/extension/3rd party
modules. on the other hand, the core should be designed in an
open-minded, non-restrictive fashion, so as to allow external
modules to extend the desired functionality.

keep it simple: that's a general design methodology, applicable
not only for this issue (which is exactly why i hate the new
metaclasses pep).


-tomer