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.

Author terry.reedy
Recipients kbk, roger.serwy, serhiy.storchaka, taleinat, terry.reedy
Date 2014-02-06.04:55:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1391662522.81.0.686459987804.issue20167@psf.upfronthosting.co.za>
In-reply-to
Content
More thoughts: The reason for explicit __del__ is to release memory resources connected to other objects or structures at the behest of the Python instance being deleted. If __del__ were only called at shutdown, it would not be needed, as all memory is released anyway and we could delete __del__. If __del__ is called before shutdown (as would happen if the class were unittested) then exceptions would indicate a bug and should not be ignored. From this viewpoint, not only should the try: except: be within the loop, but the break should be conditioned on the exception message.

  if exc.args[0] == 'can't invoke "bind" command:  application has been destroyed': break

The modern solution to this dilemma is to use .close instead of .__del__ and either explicitly call .close or have it called in the .__exit__ method of a context manager. For Idle classes, this would not be a problem for future test code, but it would be much trickier finding all places in current code where instances of a class with a .__del__ method get deleted. So a compromise patch with conditioned break seems most practical.

I tried a few more experiments: run the .py file (F5, to create a Shell window) and then close both windows. Whether the closing was shell first or editor first, the messages do not appear. Three runs with -n gave the same results. So it seems that the problem only appears when there has never been a shell window. I agree with Serhiy (his point 2) that this is disconcerting and could indicate a 3.4-specific problem with Tk, tkinter, or Idle.
History
Date User Action Args
2014-02-06 04:55:22terry.reedysetrecipients: + terry.reedy, kbk, taleinat, roger.serwy, serhiy.storchaka
2014-02-06 04:55:22terry.reedysetmessageid: <1391662522.81.0.686459987804.issue20167@psf.upfronthosting.co.za>
2014-02-06 04:55:22terry.reedylinkissue20167 messages
2014-02-06 04:55:21terry.reedycreate