2010-05-04 12 views
2

Je suis récemment revenu sur un projet qui a dû s'arrêter pendant environ 6 mois, et après avoir réinstallé mon système d'exploitation et y revenir, j'ai toutes sortes de choses folles se produire. Je me suis assuré d'installer la même version (2.6) de python que j'utilisais auparavant.Les modules Python ne sont pas mis à jour après le redémarrage du module principal

Il a commencé par me donner étrange erreur tkinter que je n'avais pas eu de problèmes avec avant, le programme est relativement simple et les 2 ou 3 bogues qui ont été laissés quand j'ai quitté, j'avais documenté et n'étaient pas liés à interface. Les choses devenaient encore plus bizarres quand la même erreur apparaissait même après avoir enlevé la section de code incriminée. En fait, le retraçage indiquait une ligne qui n'existait même pas dans le module auquel il faisait référence, par exemple: la ligne 262 alors que le module n'avait que 200 lignes. Après avoir démarré un tout nouveau fichier pour le module principal et copier/coller, il a finalement reconnu que le code incriminé avait disparu et j'ai arrêté d'obtenir l'erreur seulement pour trouver que les mises à jour du code que j'avais faites dans un autre module t apparaître lorsque j'ai redémarré le programme à travers le shell. (Je n'ai pas oublié d'enregistrer.) Après avoir joué avec cela, bien sûr, l'ancienne erreur d'interface est revenue, seulement dans une section différente du code qui avait fonctionné précédemment. En fait, si je reviens aux fichiers que j'avais il y a six mois, le programme fonctionne correctement. Cependant, dès que je change quelque chose dans le module principal, le bug de l'interface revient.

est ici l'erreur d'origine:

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 

Je devine que quelque chose d'autre qui se passe ici autre que ma propre mauvaise programmation. Quelqu'un a des idées? Edit: En repensant, je crois avoir lu quelque chose sur le fait que ce soit une mauvaise idée d'exécuter des programmes Tkinter via le shell de IDLE, et il semble au moins que le TclError ait disparu si je démarre le module principal en double-cliquant le fichier .pyc. Peut-être que mes problèmes étaient juste une combinaison de cela plus les questions de timestamp/PYTHONPATH mentionnées ci-dessous par Chris Atlee et Vlad?

Répondre

0

Vérifiez votre variable PYTHON_PATH, vous avez probablement une ancienne version du fichier.

Aussi commencer votre interpréteur Python et tapez les commandes suivantes pour vérifier le chemin:

import sys 
print sys.path 

jeter un regard attentif à la sortie et assurez-vous que vous n'avez pas vieux répertoires assis là-bas.

+0

Je n'avais pas défini PYTHONPATH et la définition du chemin python dans le répertoire entraîne l'apparition du bogue tkinter, tout comme l'impression de sys.path. Juste pour être clair: si je copie l'ancienne version (il y a six mois) du programme (juste les fichiers .py) dans un nouveau répertoire et l'exécute à partir de là à travers le shell, le programme fonctionne bien. Si j'ajoute "Print 'hello" "au début du module principal, alors l'erreur tkinter que j'ai citée précédemment est sûre de montrer dès que je clique sur un bouton sur l'interface du programme. – Ian

+0

alors que se passe-t-il lorsque vous lancez simplement l'interpréteur python et que vous imprimez sys.path obtenez-vous un résultat quelconque? – Vlad

+0

Oh, je vois, désolé. Mais oui, tout va bien ici. Juste le répertoire courant plus les répertoires python26. – Ian

2

J'ai déjà eu quelque chose de similaire. La cause de mes problèmes était que mon logiciel de contrôle de source (hg) fixait la date des fichiers à une date dans le passé. Pour cette raison, python a choisi d'utiliser des fichiers .pyc précédemment générés qui avaient des horodatages plus récents.

La solution était de supprimer tous les fichiers .pyc avant de tester le code.

+0

Les horodatages plus anciens ne semblent pas être mon problème, et parce que le programme est si petit, je n'utilise rien pour organiser des fichiers autres que de sauvegarder ce que j'ai si souvent. – Ian