What are you think about using pprint.pprint() to output the result of evaluating an expression entered in an interactive Python session (and in IDLE)?
Le Fri, 27 Sep 2013 16:55:12 +0300, Serhiy Storchaka <storchaka@gmail.com> a écrit :
I'm thinking more about the consistency of doctest output with actual interpreter output. One of the selling points of doctest is that it helps showcase API behaviour by showing interactive interpreter snippets. If the actual output starts being different, it might confuse people. Regards Antoine.
27.09.13 14:57, Antoine Pitrou написав(ла):
http://bugs.python.org/issue19103 Of course we should first resolve some other pprint-related issues (i.e. #19100, #19104).
Am 27.09.2013 12:07, schrieb Serhiy Storchaka:
This is something users can set in their sitecustomize.py; for various reasons people have already mentioned it is not a sensible choice for default interactive interpreters. It might be different for IDLE; I don't know how faithfully it follows the interactive interpreter in other regards. Georg
On 9/27/2013 12:55 PM, Georg Brandl wrote:
I agree. The default interpreter cannot be configured on the fly.
It might be different for IDLE;
It has a menu for both one-time actions and changing defaults. I think a menu item and hot-key to re-display the last output object with pprint would be a nice little feature. The object remains bound to '_' in the user process, so executing "pprint.pprint(_)" should be possible. (The minor problem is that even if pprint is loaded in sys.modules on startup, it might not be in the user global namespace.) Without seeing a bug-fixed pprint in action, I could not be sure about turning on pprint for all output. It is not needed often. The sitecustomize option would work for a permanent change.
I don't know how faithfully it follows the interactive interpreter in other regards.
We try have it act the same except where there is a good reason not to. -- Terry Jan Reedy
It's a great idea to be able to do this. Fortunately, you already can. Changing the Python default is a terrible idea for all the other reasons people mentioned, not least of which is the fact that pprint doesn't work for all inputs. I suggest writing a recipe that provides a pprint-ish replacement for repr. I suggest producing results that are identical to repr with only two exceptions: (1) adding whitespace, (2) adding line breaks to strings. While I would never add this by default, there are certainly times where I would prefer prettier output.
On Fri, Sep 27, 2013 at 01:07:18PM +0300, Serhiy Storchaka wrote:
Well, let's try it and see... py> L = list(range(50)) py> print(L) [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] py> pprint.pprint(L) [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] That would be an Absolutely Not. However, if somebody wanted to give pprint some attention to make it actually pretty print, that would be very welcome. -- Steven
On 9/27/2013 8:16 PM, Steven D'Aprano wrote:
This is why I suggested that I would consider making it available in Idle on a per object basis, for things like this
But your example is more typical of my usage.
However, if somebody wanted to give pprint some attention to make it actually pretty print, that would be very welcome.
-- Terry Jan Reedy
On Sep 27, 2013, at 3:07 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
What are you think about using pprint.pprint() to output the result of evaluating an expression entered in an interactive Python session (and in IDLE)?
This might be a reasonable idea if pprint were in better shape. I think substantial work needs to be done on it, before it would be worthy of becoming the default method of display. Raymond
On 2013-10-01 20:17, Paul Colomiets wrote:
For what it's worth, I would like to point out that IPython uses an adaptation of Armin Ronacher's pretty.py for pretty-printing as the default displayhook. It is a nice design that supports custom types after-the-fact. https://github.com/ipython/ipython/blob/master/IPython/lib/pretty.py Armin's original code: http://dev.pocoo.org/hg/sandbox/file/tip/pretty/pretty.py -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On 2 Oct 2013 05:45, "Paul Colomiets" <paul@colomiets.name> wrote:
Hi,
On Sun, Sep 29, 2013 at 11:38 PM, Serhiy Storchaka <storchaka@gmail.com>
wrote:
What should be changed in pprint?
Would be nice if it support custom types.
Fixing pprint to allow customisation was a key part of the rationale for functools.singledispatch. I guess Lukasz just hasn't had time to work on the follow-up patch to refactor the pprint module (or else I just missed it on the tracker, which is entirely plausible). Cheers, Nick.
On Sun, Sep 29, 2013 at 11:38:30PM +0300, Serhiy Storchaka wrote:
I would like to see pprint be smarter about printing lists and dicts. At the moment, a long list is either printed all on one line, like the default display, or one item per line. This can end up as one long, narrow column, which is worse than the default. I'd like to see it be smarter about using multiple columns. E.g. pprint([1, 2, 3, ... 1000]) rather than this: [1, 2, 3, ... 998, 999, 1000] something like this: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ... 991, 992, 993, 994, 995, 996, 997, 998, 999, 1000] -- Steven
On 2013-10-02 01:56, Steven D'Aprano wrote:
As someone who has used pretty-printing as their default displayhook for a decade now via IPython, I have to say that this case happens much less often than one might expect. It *is* irritating the rare times it does come up, but less so than what I expect we would see from the false positives of a more intelligent algorithm. But I withhold final judgement until I see the actual results of such an algorithm. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Le Fri, 27 Sep 2013 16:55:12 +0300, Serhiy Storchaka <storchaka@gmail.com> a écrit :
I'm thinking more about the consistency of doctest output with actual interpreter output. One of the selling points of doctest is that it helps showcase API behaviour by showing interactive interpreter snippets. If the actual output starts being different, it might confuse people. Regards Antoine.
27.09.13 14:57, Antoine Pitrou написав(ла):
http://bugs.python.org/issue19103 Of course we should first resolve some other pprint-related issues (i.e. #19100, #19104).
Am 27.09.2013 12:07, schrieb Serhiy Storchaka:
This is something users can set in their sitecustomize.py; for various reasons people have already mentioned it is not a sensible choice for default interactive interpreters. It might be different for IDLE; I don't know how faithfully it follows the interactive interpreter in other regards. Georg
On 9/27/2013 12:55 PM, Georg Brandl wrote:
I agree. The default interpreter cannot be configured on the fly.
It might be different for IDLE;
It has a menu for both one-time actions and changing defaults. I think a menu item and hot-key to re-display the last output object with pprint would be a nice little feature. The object remains bound to '_' in the user process, so executing "pprint.pprint(_)" should be possible. (The minor problem is that even if pprint is loaded in sys.modules on startup, it might not be in the user global namespace.) Without seeing a bug-fixed pprint in action, I could not be sure about turning on pprint for all output. It is not needed often. The sitecustomize option would work for a permanent change.
I don't know how faithfully it follows the interactive interpreter in other regards.
We try have it act the same except where there is a good reason not to. -- Terry Jan Reedy
It's a great idea to be able to do this. Fortunately, you already can. Changing the Python default is a terrible idea for all the other reasons people mentioned, not least of which is the fact that pprint doesn't work for all inputs. I suggest writing a recipe that provides a pprint-ish replacement for repr. I suggest producing results that are identical to repr with only two exceptions: (1) adding whitespace, (2) adding line breaks to strings. While I would never add this by default, there are certainly times where I would prefer prettier output.
On Fri, Sep 27, 2013 at 01:07:18PM +0300, Serhiy Storchaka wrote:
Well, let's try it and see... py> L = list(range(50)) py> print(L) [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] py> pprint.pprint(L) [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] That would be an Absolutely Not. However, if somebody wanted to give pprint some attention to make it actually pretty print, that would be very welcome. -- Steven
On 9/27/2013 8:16 PM, Steven D'Aprano wrote:
This is why I suggested that I would consider making it available in Idle on a per object basis, for things like this
But your example is more typical of my usage.
However, if somebody wanted to give pprint some attention to make it actually pretty print, that would be very welcome.
-- Terry Jan Reedy
On Sep 27, 2013, at 3:07 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
What are you think about using pprint.pprint() to output the result of evaluating an expression entered in an interactive Python session (and in IDLE)?
This might be a reasonable idea if pprint were in better shape. I think substantial work needs to be done on it, before it would be worthy of becoming the default method of display. Raymond
On 2013-10-01 20:17, Paul Colomiets wrote:
For what it's worth, I would like to point out that IPython uses an adaptation of Armin Ronacher's pretty.py for pretty-printing as the default displayhook. It is a nice design that supports custom types after-the-fact. https://github.com/ipython/ipython/blob/master/IPython/lib/pretty.py Armin's original code: http://dev.pocoo.org/hg/sandbox/file/tip/pretty/pretty.py -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On 2 Oct 2013 05:45, "Paul Colomiets" <paul@colomiets.name> wrote:
Hi,
On Sun, Sep 29, 2013 at 11:38 PM, Serhiy Storchaka <storchaka@gmail.com>
wrote:
What should be changed in pprint?
Would be nice if it support custom types.
Fixing pprint to allow customisation was a key part of the rationale for functools.singledispatch. I guess Lukasz just hasn't had time to work on the follow-up patch to refactor the pprint module (or else I just missed it on the tracker, which is entirely plausible). Cheers, Nick.
On Sun, Sep 29, 2013 at 11:38:30PM +0300, Serhiy Storchaka wrote:
I would like to see pprint be smarter about printing lists and dicts. At the moment, a long list is either printed all on one line, like the default display, or one item per line. This can end up as one long, narrow column, which is worse than the default. I'd like to see it be smarter about using multiple columns. E.g. pprint([1, 2, 3, ... 1000]) rather than this: [1, 2, 3, ... 998, 999, 1000] something like this: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ... 991, 992, 993, 994, 995, 996, 997, 998, 999, 1000] -- Steven
On 2013-10-02 01:56, Steven D'Aprano wrote:
As someone who has used pretty-printing as their default displayhook for a decade now via IPython, I have to say that this case happens much less often than one might expect. It *is* irritating the rare times it does come up, but less so than what I expect we would see from the false positives of a more intelligent algorithm. But I withhold final judgement until I see the actual results of such an algorithm. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (11)
-
Antoine Pitrou -
Bruce Leban -
Eric V. Smith -
Georg Brandl -
Nick Coghlan -
Paul Colomiets -
Raymond Hettinger -
Robert Kern -
Serhiy Storchaka -
Steven D'Aprano -
Terry Reedy