1

While working on an image file I have, I tried reading it into a string and printing it on my IDLE 3.6. The string is roughly 160K bytes long and I already saved it into a txt file on my machine. That took about a second, so I figured printing it would take about the same...

Never have I been so wrong...

Now, I checked this and the first answer suggests that the print itself is problematic. In their case, the format was non-standard, so I'm not sure if my case is the same. Second, if the print is the problem, why the IDLE seem to be slow after the print is done?

This is how I run it:

with open(location_of_160KB_png_file, "rb") as imageFile:
    f = imageFile.read()
    b = bytearray(f)
    b=''.join([str(bb) for bb in b])
    b[:10]    # this prints easily (on IDLE I don't have to use _print_ function, I can just type the variable name)
    b         # this, however...
CIsForCookies
  • 12,097
  • 11
  • 59
  • 124

1 Answers1

1

The issue, as explained in the answers to the link you gave, is that the tk Text widget is optimized for handling short lines. I have loaded IDLE's Shell with over 500000 lines of maybe 40 chars. That is 20 million chars, way larger than any file a person would write. It is well suited for the intended use.

In the referenced link, a 10000 char line is built 1 char at a time. Tk Text bogs down somewhere in the low 1000s. You apparently threw 160000 chars all at once. 10000 all at once is enough.

PS: Echoing expressions without a print statement is standard Python interactive interpreter behavior. I an fairly sure that this was probably copied from predecessors.

Terry Jan Reedy
  • 18,414
  • 3
  • 40
  • 52
  • Thx!! but what I'm really looking for is the why... how come that after the line is printed I still have slow reactions? I thought maybe it fills up the RAM but that's less than 200KB which is basically nothing (16GB machine) – CIsForCookies Jul 12 '17 at 05:34
  • I actually answered in condensed fashion. As you noted, the initial insertion is not the problem. The problem is the interaction between the long line already inserted into the text widget and the code of how the widget changes what you see when you move the cursor or insert further text. For this unusual case, I suspect responsiveness would work better if line wrapping were turned off, with or without a scrollbar added. (I plan to experiment.) – Terry Jan Reedy Jul 12 '17 at 22:31