This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: IDLE shell window gets very slow when displaying long lines
Type: performance Stage:
Components: IDLE Versions: Python 3.8
Status: open Resolution:
Dependencies: 1529353 Superseder:
Assigned To: terry.reedy Nosy List: THRlWiTi, ajaksu2, drhok, gpolo, kbk, louielu, rhettinger, roger.serwy, terry.reedy
Priority: normal Keywords: patch

Created on 2006-03-03 14:45 by drhok, last changed 2022-04-11 14:56 by admin.

File name Uploaded Description Edit
manual_wrap.patch roger.serwy, 2013-04-04 00:47 review
0001-IDLE-shell-test.patch louielu, 2017-07-18 05:05
Messages (19)
msg27661 - (view) Author: Heiko Selber (drhok) Date: 2006-03-03 14:45
I wrote a little python script that prints a large 
dictionary to stdout (simply using 'print 

In fact, the type is irrelevant, what matters is that 
the resulting output had approx. 200,000 characters.

The shell prints the dictionary into a single line, 
which causes the window to be almost non-responding, 
e.g. when I try to scroll the window.

Even on a high-end PC it takes a minute or even 
longer to react to anything.

I use Python 2.4.2 on Windows XP SP2.

I am aware that it is not exactly wise to print such 
large objects, but I usually print return values to 
stdout when I debug a script, and I do not always 
expect an object to be that large.

The average text editor handles such long lines much 

A quick workaround might be to break very long lines 
automagically (perhaps at around column 1000).

PS: I already observed the bug some years ago. I 
think I even submitted it to python or idlefork a 
long time ago but I was unable to find it in the 
msg27662 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2006-03-09 23:45
Logged In: YES 

I verified this with print 100000*'a', also XP (home) sp2.
The sluggishness continued after getting the prompt back 
and trying to do something simple, like 2+2, taking maybe 
1/2 minute to print 4 and then the >>> prompt again.
The sluggishness *also* continued after restarting the 
shell (^F6).  This indicates that the problem is with the 
window, not with IDLE.  Hope someone can try same on *nix 
system to see if general with TKinter or specific to Win 
msg27663 - (view) Author: Josiah Carlson (josiahcarlson) * (Python triager) Date: 2006-03-10 20:18
Logged In: YES 

Generally speaking, most wrapping text controls have issues
with wrapping long lines.  It would seem reasonable to get
the width of the text control in characters, and manually
wrap all incoming lines regardless.  If the existance or not
of real line endings are important, one could mark which
lines are manually wrapped and remove the line endings on
copy (edit->copy, ctrl+c, etc.).
msg27664 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2006-03-28 23:08
Logged In: YES 

This is a known problem with Tk/Tcl/tkinter - large output 
scrolls slowly. It's not something that can be fixed in IDLE.  I 
tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4.  250,000 character 
output not too bad , 25 sec, but 10,000 lines of 25 char takes 
over twice that long, so breaking the lines doesn't help.

I don't see any response problem once the output completes.  The 
situation is exponentially worse at 500,000 char.

What is your use case?  IDLE is designed to be an IDE.  Why 
output such massive data?

You may be interested in Squeezer, a Noam Raphael extension to 

I haven't tried it myself, but it might be what you're looking 
msg27665 - (view) Author: Heiko Selber (drhok) Date: 2006-03-29 20:19
Logged In: YES 

Hi kbk,

well, my use case is debugging. I write a script and run it
with IDLE. It doesn't behave as expected, so I insert a
print statement. Next time I run it, IDLE hangs. Oops, it
was a long array; it should have been an int. Line too long.

OK, I wait through it, correct the bug, run it again. What
happens? IDLE hangs again, trying to scroll a long line (of
the previous run).

Never mind, I can always kill the process... Dammit, I
can't! It eats 100% CPU; task manager doesn't respond.

IMHO his takes away one of python's strengths, which is
making quick hacks really quick.

Would you suggest redirecting this issue to tkinter? You
don't seem to consider this an issue at all.

I will give squeezer a try. Or maybe PyDev?
msg27666 - (view) Author: Josiah Carlson (josiahcarlson) * (Python triager) Date: 2006-03-29 20:35
Logged In: YES 

You can close the window which includes the Shell that has
the huge output, or even reduce the priority of your Idle
shell (you can make it automatic by mucking about with the
shortcut; see the 'start' command).
msg27667 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2006-03-29 20:52
Logged In: YES 

It's not that I don't consider it an issue, but I can't
do anything to improve the performance of the Tk text
widget.  IDLE is pure Python.

One thing that comes to mind is to set a maximum line 
length.  If the line exceeds that, print line(:(MAX -100)
+ '...' + line(:-100)  instead of printing the whole thing
which no one wants to look at anyway.

Another thing I've wanted to do is provide the ability
to clear the shell window when it gets too full, w/o
restarting IDLE.

Yes, you might ask the tkinter guys on their mail list,
I'd be interested in hearing their reply.
msg27668 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2006-07-26 17:56
Logged In: YES 

The Squeezer extension works like a charm! It's also been
thoroughly tested by tens of users over the past several years.

Why not include it as one of the default extensions, and
have it enabled by default?

BTW I have a tweaked version of Squeezer (I fixed the line
counting code), if you're interested.
msg27669 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2006-07-26 20:38
Logged In: YES 

Sure, please open a patch and supply a diff against
Noam's version.
msg27670 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2006-07-26 23:35
Logged In: YES 

msg27671 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2006-10-07 17:45
Logged In: YES 

Patch 1529353 by Tal Einat
msg86626 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-04-26 22:21
Patch review in issue 1529353.
msg185296 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-03-26 20:07
print(100000*'a') is still a problem in 3.3.
msg185459 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2013-03-28 18:27
In addition to squeezing, it would be nice (and easy) to add a menu option (and hotkey) to clear the text pane.
msg185475 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-03-28 23:59
@Raymond, see issue6143 for an (outdated) extension to clear the shell window with a hotkey.
msg185986 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2013-04-04 00:47
The only reason that the IDLE shell is slow is due to the shell's text widget being configured to have wrap="char". If we manually wrapped the output then the shell responds very quickly to rendering really long strings.

The attached proof-of-concept patch (against 2.7 tip) implements manual wrapping. You can type "print('a' * 10**6)" and the shell responds almost instantly when using no-subprocess mode. (The RPC overhead becomes readily apparent when using a subprocess, introducing a large uninteruptable delay. That's another issue.)

I left text wrapping enabled in the shell since the user may be using a variable-spaced font. A possible compromise would be to increase the wrap_index to a large number, like 32768, before IDLE inserts a '\n' into the output. This would mimic the wrapping behavior of the original shell, but keep the shell responsive when you write a very long string to the output.
msg272787 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-08-15 17:49
manual_wrap.patch patches OutputWindow (2.7) to arbitrarily and blindly wrap at 80 chars.  OutputWindow is used directly for grep output, as well as the base for PyShell.  The grep output format is currently "'{}: {}: {}'.format(filepath, linenum, codeline)".  Output lines are typically (for me) > 80 chars and I would not want a fixed-column wrap.  With a right click, one can go to the file and line and this should not be disabled.  Ditto for tracebacks, where code lines are pre-wrapped (with an added indent) onto a second physical line. Wrap at 80 would wrap lines that were originally 80 before having the traceback indent added.  Autowrap should only be applied to user stdout sent to Shell.

Perhaps wrapping should have a window (80-100?) within which we look for a space.  I have about concluded that we should add horizontal scrollbars anyway, since Python and IDLE output lines longer than 80 chars.

To evaluate the patch further, I want to look at how the socket stream is being read.

As long as we are modifying user output before inserting into the text widget, astral chars should be expanded into their unicode escapes. (There are multiple issue for astral chars.  Tk 8.7 reportedly will handle them.) The replacement text should be tagged and colored as such.  Wrapping should not break replacements.  The same could be done for control chars to make them visible.  (Astral char handling is needed for paths also!).
msg298575 - (view) Author: Louie Lu (louielu) * Date: 2017-07-18 05:05
Besides warping text, there has a performance issue inside the RPCServer and Client.

The (console, write, (text, file), {}) command is sent by server `asynccall`->`putmessage`. It should be sent by chunk size to client, and render on IDLE shell.

The result is performed as sent by chunk size, but the client will gather all chunk until it receives all data, then render on IDLE shell.

This cause the shell seems like hanging there, and doing nothing (in REPL, it will output the long string to stdout and so on).

We can manually detect this then manully chunk out (console, write, args, kwargs) command's args size, so that it will look like not hanging there.

The attach patch is a PoC about this.


For the text widget performance, I dislike the wrap method, it shouldn't be a limit to the user on IDLE (GUI IDE), even it can be set to 80 or 100 or whatever.
msg336441 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-02-24 06:37
Squeezer was added last summer, and definitely helps, but I still intend to consider other points raised here.
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42973
2019-05-02 04:14:01josiahcarlsonsetnosy: - josiahcarlson
2019-02-24 06:37:48terry.reedysetmessages: + msg336441
2019-02-24 06:35:29terry.reedysetversions: + Python 3.8, - Python 2.7, Python 3.3, Python 3.4, Python 3.7
2017-07-18 05:05:17louielusetfiles: + 0001-IDLE-shell-test.patch
versions: + Python 3.7
nosy: + louielu

messages: + msg298575
2016-08-16 06:56:13terry.reedylinkissue27750 superseder
2016-08-16 06:45:29terry.reedysetassignee: terry.reedy
2016-08-15 17:49:56terry.reedysetmessages: + msg272787
2016-05-22 04:18:59terry.reedylinkissue27082 superseder
2015-05-01 11:56:59THRlWiTisetnosy: + THRlWiTi
2014-02-04 12:05:26taleinatsetnosy: - taleinat
2013-04-04 00:47:44roger.serwysetfiles: + manual_wrap.patch
keywords: + patch
messages: + msg185986

versions: - Python 3.2
2013-03-28 23:59:39roger.serwysetnosy: + roger.serwy
messages: + msg185475
2013-03-28 18:27:14rhettingersetnosy: + rhettinger
messages: + msg185459
2013-03-26 20:07:06terry.reedysetmessages: + msg185296
versions: + Python 3.3, Python 3.4, - Python 3.1
2010-08-22 01:58:06BreamoreBoysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6, Python 3.0
2009-04-26 22:21:36ajaksu2setnosy: + ajaksu2, gpolo

messages: + msg86626
stage: test needed ->
2009-03-21 00:45:51ajaksu2setdependencies: + Squeezer - squeeze large output in IDLE's shell
type: performance
stage: test needed
versions: + Python 2.6, Python 3.0, - Python 2.4
2006-03-03 14:45:24drhokcreate