Wenn ich selbst das folgende lesen würde, würde ich denken "Der Typ hat eines an der Waffel"... Dennoch, das Probelem existiert tatsächlich und ist beliebig oft reproduzierbar.
Ich habe ein Programm geschrieben, das bei völlig gleichem Input einmal tut und einmal nicht. Den Fehler habe ich mittlerweile 20, 30 mal reproduzieren können, kann mir die Ursache aber überhaupt nicht erklären. Wenn ich das entsprechende Python Modul vor der Ausführung des Codes einmal öffne und speichere, funktioniert das Programm ganz genau ein Mal. Führe ich den Code ein zweites Mal aus, taucht ein Fehler auf.
Ich kann das Programm beliebig oft neu laufen lassen, es wird nicht korrekt funktionieren. Erst dann, wenn ich das Python Modul, wie oben geschrieben, wieder einmal öffne und speichere, funktioniert der Code wieder ein mal.
Habt ihr so ein Verhalten schon einmal festgestellt?? Ich bin gerade völlig ratlos und verstehe die Welt wirklich nicht mehr.
Ich teste auf Fedora Core 3 Kisten mit Python 2.3 auf denen ich mich per SSH eingeloggt habe - falls das irgendwie wichtig ist!a
Unerklärlicher Fehler mit Python 2.3
Bei mir passiert sowas immer bei Threads 
Aber mal im Ernst, wahrscheinlich initialisiert sich das Modul und nachdem damit gearbeitet wurde, ist dieser Status als Anfangsstatus nicht mehr gueltig.
Erst wenn du die Datei oeffnest und dann wieder speicherst wird das Modul neu geladen und erneut initalisiert. Wahrscheinlich machst du also irgendwelche Änderungen auf einer globalen Variable des Moduls.

Aber mal im Ernst, wahrscheinlich initialisiert sich das Modul und nachdem damit gearbeitet wurde, ist dieser Status als Anfangsstatus nicht mehr gueltig.
Erst wenn du die Datei oeffnest und dann wieder speicherst wird das Modul neu geladen und erneut initalisiert. Wahrscheinlich machst du also irgendwelche Änderungen auf einer globalen Variable des Moduls.
Es gibt leider keine Fehlerausgabe (von Python) die ich euch geben könnte, sonst hätte ich das natürlich getan.
Der Teil des Programms, der "spinnt" ist eine Methode innerhalb eines recht umfangreichen Parsers, die nichts anderes tut als Leerzeichen vom Beginn eines Strings zu entfernen.
Meine Debug-Ausgaben und die Ergebnisse des Programms sagen mir, dass diese Methode zwar immer brav aufgerufen wird, aber im Fehlerfall einfach nicht korrekt arbeitet und sich beendet.
Das Problem liegt nicht an Threads, da keine Threads in dem Programm gebraucht werden. Und im Grunde kann ein Problem mit falscher Initialisierung auch ausgeschlossen werden, da das Programm sich pro Testlauf beendet und erst per Konsolenkommando neu gestartet werden muss.

Der Teil des Programms, der "spinnt" ist eine Methode innerhalb eines recht umfangreichen Parsers, die nichts anderes tut als Leerzeichen vom Beginn eines Strings zu entfernen.
Meine Debug-Ausgaben und die Ergebnisse des Programms sagen mir, dass diese Methode zwar immer brav aufgerufen wird, aber im Fehlerfall einfach nicht korrekt arbeitet und sich beendet.
Das Problem liegt nicht an Threads, da keine Threads in dem Programm gebraucht werden. Und im Grunde kann ein Problem mit falscher Initialisierung auch ausgeschlossen werden, da das Programm sich pro Testlauf beendet und erst per Konsolenkommando neu gestartet werden muss.
Was heisst "sich beendet"? Es gibt drei Möglichkeiten, wie eine Funktion/Methode verlassen wird: Explizites ``return``, implizites Beenden wenn der Kontrollfluss das Ende der Funktion erreicht, oder eine Ausnahme. Welcher Weg wird also gewählt?
Ich habe den Fehler jetzt.
Der Code führt eine While-Schleife aus und testet pro Durchgang, ob das erste Zeichen eines Strings ein Leerzeichen ist. Dummerweise habe ich den Vergleich vor 3 Monaten mit "is" gemacht, was natürlich völliger blödsinn ist und das fiel mir partout bis eben nicht auf.
Damals hab ich das so gemacht: while char is " ":
Richtig ist natürlich while char == " ":
Der Inhalt der Schleife wurde dann nie ausgeführt und das Programm hat einen unveränderten Eingabewert zurück gegeben. Das war der Fehler.
Witzig ist aber, dass Python 2.3 sich völlig anders verhält, als es Python 2.4 und 2.5 tun... Ganz logisch ist das alles jedenfalls nicht!
Ich habe vorhiin auch noch festgestellt, dass ein Löschen der Bytecode-Dateien das Problem, ähnlich wie Modul öffnen/speichern, für einen Programmstart behoben hat.
Der Code führt eine While-Schleife aus und testet pro Durchgang, ob das erste Zeichen eines Strings ein Leerzeichen ist. Dummerweise habe ich den Vergleich vor 3 Monaten mit "is" gemacht, was natürlich völliger blödsinn ist und das fiel mir partout bis eben nicht auf.
Damals hab ich das so gemacht: while char is " ":
Richtig ist natürlich while char == " ":
Der Inhalt der Schleife wurde dann nie ausgeführt und das Programm hat einen unveränderten Eingabewert zurück gegeben. Das war der Fehler.
Witzig ist aber, dass Python 2.3 sich völlig anders verhält, als es Python 2.4 und 2.5 tun... Ganz logisch ist das alles jedenfalls nicht!
Ich habe vorhiin auch noch festgestellt, dass ein Löschen der Bytecode-Dateien das Problem, ähnlich wie Modul öffnen/speichern, für einen Programmstart behoben hat.
Warum, wenn man "is" so verwendet wie vorgesehen, macht das gar keinen Unterschied. Ich würde mal davon ausgehen, dass der Caching-Mechanismus für kurze Strings angepasst wurde, daher das unterschiedliche Verhalten zwischen den Python-Versionen.antaeus hat geschrieben: Witzig ist aber, dass Python 2.3 sich völlig anders verhält, als es Python 2.4 und 2.5 tun... Ganz logisch ist das alles jedenfalls nicht!
Aber andere kennen sich hier mit den "Internals" der Interpreter wahrscheinlich besser aus, das mit dem Caching also nur mal so eine Vermutung von mir.
EyDu, komisch ist es aber dennoch das wenn er das Modul einmal Speicher es dann beim ersten run geht.
@antaeus:
Ist das Problem mit dem löschen der pyc Datei nun vollkommene behoben oder musst du nach jedem run die pyc Datei wider löschen? Würde mich interessieren wie sich das verhält. Wen du nichts dagegen hast, könntest du das ja mal ohne deine Änderung ``while char == " ": `` testen. Weil, eigentlich sollte Python die pyc Datein jedesmal mit einer aktuellen ersetzen, wenn sich die Checksumme der py-Datei geändert hat
@antaeus:
Ist das Problem mit dem löschen der pyc Datei nun vollkommene behoben oder musst du nach jedem run die pyc Datei wider löschen? Würde mich interessieren wie sich das verhält. Wen du nichts dagegen hast, könntest du das ja mal ohne deine Änderung ``while char == " ": `` testen. Weil, eigentlich sollte Python die pyc Datein jedesmal mit einer aktuellen ersetzen, wenn sich die Checksumme der py-Datei geändert hat

In alten Python Versionen wahr es tatsächlich so, das ein "in"-test nur mit einem Zeichen ging. Das wurde erst in späteren Versionen erweitert, das es auch bei ganzen strings geht.EyDu hat geschrieben: Warum, wenn man "is" so verwendet wie vorgesehen, macht das gar keinen Unterschied. Ich würde mal davon ausgehen, dass der Caching-Mechanismus für kurze Strings angepasst wurde, daher das unterschiedliche Verhalten zwischen den Python-Versionen.
@antaeus:
Ist das Problem mit dem löschen der pyc Datei nun vollkommene behoben oder musst du nach jedem run die pyc Datei wider löschen? Würde mich interessieren wie sich das verhält. Wen du nichts dagegen hast, könntest du das ja mal ohne deine Änderung ``while char == " ": `` testen. Weil, eigentlich sollte Python die pyc Datein jedesmal mit einer aktuellen ersetzen, wenn sich die Checksumme der py-Datei geändert hat
[/quote]
Nein, ich musste nach jedem run die pyc-Datei löschen, damit der Code funktioniert. Vollkommen gelöst war das Problem also durch einmaliges Löschen nicht.
Schon interessant, wie unterschiedlich sich die Versionen verhalten. Hoffentlich tauchen da nicht n och mehr solcher Probleme auf...
Ist das Problem mit dem löschen der pyc Datei nun vollkommene behoben oder musst du nach jedem run die pyc Datei wider löschen? Würde mich interessieren wie sich das verhält. Wen du nichts dagegen hast, könntest du das ja mal ohne deine Änderung ``while char == " ": `` testen. Weil, eigentlich sollte Python die pyc Datein jedesmal mit einer aktuellen ersetzen, wenn sich die Checksumme der py-Datei geändert hat

Nein, ich musste nach jedem run die pyc-Datei löschen, damit der Code funktioniert. Vollkommen gelöst war das Problem also durch einmaliges Löschen nicht.
Schon interessant, wie unterschiedlich sich die Versionen verhalten. Hoffentlich tauchen da nicht n och mehr solcher Probleme auf...
Nur mal so wild geraten: Beim Übersetzen wird der Compiler irgendwann an der Konstanten Zeichenkette ' ' (das eine Leerzeichen) vorbeikommen und vielleicht nur bei diesem Übersetzen die Zeichenkette im Cache ablegen, so das bei diesem einen Programmlauf das ``is`` funktioniert.
Aber mal so nebenbei: Die Funktion baut nicht auf umständliche Weise eine der `str.strip()`-Methoden nach, oder?
Aber mal so nebenbei: Die Funktion baut nicht auf umständliche Weise eine der `str.strip()`-Methoden nach, oder?