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
On 8/10/07, wrobell
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
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>
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.
On Aug 11, 2:14 am, Adam Atlas
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
participants (5)
-
Adam Atlas -
Brett Cannon -
Fred Drake -
tomer filiba -
wrobell