In Jan 2014 in the opening messages of bpo-20167, msg207599, Serhiy Storchaka reported that
./python -m idlelib.idle Lib/decimal.py
opened the file on both 2.7 and 3.4 (beta) but that closing on 3.4 (but not 2.7) caused 'application closed' errors in Multicall .__del__ methods. These have been fixed and recently refixed.

In msg228954, Serhiy reported a new problem, which I an transferring to this new issue, with 2.7 and 3.4 but not 3.5.

./python -m idlelib.idle Lib/decimal.py
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.4/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpython-3.4/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/PyShell.py", line 1562, in main
    if flist.open(filename) is None:
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/FileList.py", line 36, in open
    edit = self.EditorWindow(self, filename, key)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/PyShell.py", line 141, in __init__
    self.color_breakpoint_text()
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/PyShell.py", line 159, in color_breakpoint_text
    self.text.tag_config('BREAK', cfg)
AttributeError: 'NoneType' object has no attribute 'tag_config'

Serhiy, you did not specify the particular binaries you used. I will assume recent.

Versions: as far as I know, there are no idlelib code differences between 3.4 and default (3.5). I rechecked closed issues for patches pushed by someone else only to 3.5. So any behavior difference between 3.4 and 3.5 must by due to a difference in tkinter, another stdlib module, or python itself.

What system? I do not reproduce on Win 7 with an Oct 9 build.

When? If the command line worked for 2.7 in Jan and fails now, when did it start failing? If the command worked for 3.4 after the Feb patches and fails now, same question.

How? You did not state, but in a later message implied that the file opened in the editor and the problem only happened when you closed, as with the January report. However, the traceback says that the problem occurred during initialization. According to Find in Files, the only call to color_breakpoint_text is that one __init__ call. I therefore do not understand your msg228957 comment "The code runs up to self.text.update() in restore_file_breaks() and runs further only after windows closing."

restore_file_breaks is only called in two places. One is when file names are changed (which should not happen when closing an untouched file), the other is just before color_break during initialization. Here is the last part of PyShellEditorWindow.__init__.

        def filename_changed_hook(old_hook=self.io.filename_change_hook,
                                  self=self):
            self.restore_file_breaks()
            old_hook()
        self.io.set_filename_change_hook(filename_changed_hook)
        if self.io.filename:
            self.restore_file_breaks()
        self.color_breakpoint_text()

You msg228958 comment that changing .update to .update_idletasks also puzzles me. According to the tkinter docstrings, the difference is that the latter does less (assuming that .update also clears non-user callbacks, whatever they are)

update(self)
    Enter event loop until all pending events have been processed by Tcl.

update_idletasks(self)
    Enter event loop until all idle callbacks have been called. This
    will update the display of windows but not process events caused by
    the user.

During initialization, I would not expect there to be any user events.

In msg228954, Serhiy reported a new problem, which I an transferring to this
new issue, with 2.7 and 3.4 but not 3.5.

I now can reproduce the issue on 3.5 too. But with Lib/test/test_decimal.py, not Lib/decimal.py. The difference between 3.4 and 3.5 is that Lib/decimal.py is large in 3.4, but it is tiny in 3.5.

I can easy reproduce this issue because my netbook is too slow. When I wait some time, and then close editor window, there is no traceback. This time is needed to colorize sources in editor window. May be you will reproduce this issue when open very large Python file and then quickly close editor window. If you have no such file, just concatenate large file with itself many times:

cp [Lib/test/test_decimal.py](https://github.com/python/cpython/blob/main/Lib/test/test_decimal.py)+[Lib/test/test_decimal.py](https://github.com/python/cpython/blob/main/Lib/test/test_decimal.py)+[Lib/test/test_decimal.py](https://github.com/python/cpython/blob/main/Lib/test/test_decimal.py)+[Lib/test/test_decimal.py](https://github.com/python/cpython/blob/main/Lib/test/test_decimal.py)+[Lib/test/test_decimal.py](https://github.com/python/cpython/blob/main/Lib/test/test_decimal.py) testfile.py

What system? I do not reproduce on Win 7 with an Oct 9 build.

I believe you will reproduce with enough large file.

When? If the command line worked for 2.7 in Jan and fails now, when did it
start failing? If the command worked for 3.4 after the Feb patches and
fails now, same question.

At least with 3.4.0 I don't see this traceback. May it is hidden by the 'can't invoke "bind" command' error.

How? You did not state, but in a later message implied that the file opened
in the editor and the problem only happened when you closed, as with the
January report. However, the traceback says that the problem occurred
during initialization. According to Find in Files, the only call to
color_breakpoint_text is that one __init__ call. I therefore do not
understand your msg228957 comment "The code runs up to self.text.update()
in restore_file_breaks() and runs further only after windows closing."

Sorry for my ugly English. I meant that the interpreter enters in self.text.update(), then hangs inside it and exits from it only when the windows is closed. I added print's before and after this statement and the print after the statement was not executed until I had closed the window.

Makes sense now. Large file relative to machine speed + quick close click = close (at least to point of destruction of self.text) before initialization is complete. Hence continued initialization fails. Yes, when closing crashed in Multicall, would not see initialization after close error.

Switch to .update_idletasks ignores close event, hence initialization gets to complete without error. Do we want to do that? I think not. If one tries to edit gigabyte file, idle/tk will probably hang and one very well might want close event handled. We could instead wrap test.tag_config with try: except AttributeError. Original authors assumed this would never happen, but its occurrence seems like a rare but legitimate possibility that should be allowed for.

After sleeping, I will try to reproduce on my fast machine using Windows copy command. 3k EditorWindow.py is colorized too fast.

Here is a patch which should fix this issue. The same solution already is used
in restore_file_breaks().

New changeset a4c1c9b534a2 by Terry Jan Reedy in branch '2.7':
Issue bpo-22614: Don't try to update deleted text. Patch by Serhiy Storchaka.
https://hg.python.org/cpython/rev/a4c1c9b534a2

New changeset d686de84dc10 by Terry Jan Reedy in branch '3.4':
Issue bpo-22614: Don't try to update deleted text. Patch by Serhiy Storchaka.
https://hg.python.org/cpython/rev/d686de84dc10

New changeset 4163079a717a by Terry Jan Reedy in branch 'default':
Merge with 3.4 bpo-22614
https://hg.python.org/cpython/rev/4163079a717a