views:

73

answers:

2

I've recently come back to a project having had to stop for about 6 months, and after reinstalling my operating system and coming back to it I'm having all kinds of crazy things happen. I made sure to install the same version(2.6) of python that I was using before.

It started by giving me strange tkinter error that I hadn't had trouble with before, the program is relatively simple and the 2 or 3 bugs that were left when i quit, I had documented and weren't related to the interface.

Things got even weirder when the same error would pop up even after I had removed the offending section of code. In fact, the traceback pointed to a line that didn't even exist in the module it was referencing, eg: line 262 when the module was only 200 lines long.

After just starting a completely new file for the main module and copy/pasting it finally recognized that the offending code was gone and I stopped getting the error only to find that any updates to the code I made in another module didn't show up when I restarted the program through the shell. (I didn't forget to save.) After fiddling with this, of course, the old interface error came back, only in a different section of code that had been working previously.

In fact, if I revert back to the files I had six months ago, the program works fine. As soon as I change anything in the main module, however, the interface bug comes back.

Here's the original error:

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
return self.func(*args)
  File "C:\PyStuff\interface.py", line 202, in dispOne
__main__.top.destroy()
  File "C:\Python26\lib\lib-tk\Tkinter.py", line 1938, in destroy
    self.tk.call('destroy', self._w)
TclError: can't invoke "destroy" command:  application has been destroyed

I'm guessing something else is going on here other than my own poor programming. Anyone have any ideas?

Edit: Thinking back, I believe I read something about it being a bad idea to run Tkinter programs through IDLE's shell, and it appears, at least, that the TclError has vanished if I instead start the main module by double clicking the .pyc file. Perhaps my problems were just a combination of that plus the timestamp/PYTHONPATH issues mentioned below by Chris Atlee and Vlad?

A: 

Check your PYTHON_PATH variable, you probably have an older version of the file.

Also start your python interpreter and type the following commands to check the path:

import sys
print sys.path

Take a careful look at the output and make sure you don't have any old directories sitting there.

Vlad
I hadn't set PYTHONPATH, and setting python path to the directory causes the tkinter bug to pop up, as does printing sys.path. Just to be clear: if I copy the old (six months ago) version of the program(just the .py files) into a new directory and run it from there through the shell, the program works fine. If I add "Print 'hello'" to the beginning of the main module, then the tkinter error i quoted previously is sure to show as soon as i click a button on the interface of the program.
Ian
so what happens when you just start the python interpreter and print out sys.path do you get any kind of output?
Vlad
Oh I see, sorry.But yeah, everything looks fine there. Just the current directory plus the python26 directories.
Ian
Although, I should point out, that after setting pythonpath to the current directory in my main module, the problems with updating modules have gone away so perhaps something along these lines was going on. Despite this, I still get the TCL error if I run the program through IDLE's shell, and I don't get that error if I just double click the .py or .pyc files.
Ian
Try printing out the sys.path from the IDLE shell. I believe it has an interactive shell feature. Also search for .pyc files on your system and delete old files, it could be that the date are messed up on these compiled files.
Vlad
+2  A: 

I've had something similar happen. The cause for my problems was that my source control software (hg) was setting the date of files to a date in the past. Because of this, python chose to use previously generated .pyc files which had newer timestamps.

The solution was to delete all the .pyc files before testing the code.

Chris AtLee
Older timestamps don't seem to be my problem, and because the program is so small I don't use anything to organize files other than backing up what I have every so often.
Ian