Syntaxfehler nach kopieren eines Scriptes auf anderen PC

[meneliel]

Hallo,

ich steh gerade vor einem Problem, welches mich ziemlich verzweifeln lässt, und auch meine Kollegen haben keine Idee mehr.

Ich habe ein Script, welches Klassen benutzt, die in einem anderen Python-File liegen. Das Script lief auch problemlos, auf meinem lokalen PC.
Nachdem ich die Scripte und alle benötigten Dateien auf einen Server hochkopiert habe, auf dem das Script letzendlich laufen soll, habe ich ziemlich komische Fehlermeldungen bekommen.

Auf dem Server habe ich auch leider nur IDLE und starte zum Testen auch von dort das Script. Zum Schluss startet es sich jeden Tag um die gleiche Zeit automatisch. Jedenfalls, nachdem ich mein Main-Script starte, werden ständig komische Syntax-Fehler gefunden in dem File mit den Klassen.

Das Problem kenne ich schon aus MyEclipse mit Pydev, aber dort hift es entsprechende Zeile einfach zu kopieren und wieder einzufügen.

Fehlermeldungen sehen dann so aus:

Code: Alles auswählen

Traceback (most recent call last):
  File "C:\xx\xx\xg.py", line 11, in ?
    import SQL_queries as SQL
  File "C:\xxx\xx\SQL_queries.py", line 347
    pl3 = self.delete_sum_row(plot_list_3)
        plotstring = ((pl1[0],pl1[1],"g","Costlevel 1"),(pl2[0],pl2[1],"r","Costlevel 2"),(pl3[0],pl3[1],"b","Costlevel 3"))
                                          ^
SyntaxError: invalid syntax

Ich sehe jetzt hinter der Klammer mit dem (plot_list_3) ein kleines Quadrat (erscheint hier so kleider nicht). Aber selbst mit Ultraedit im Hexadezimal-Modus ist da nur ein Zeilenumbruch zu sehen.
Ich habe die Zeilen neugeschrieben, hat nix gebracht. Ein Kollege von mir, hat einfach an das Zeilenende ein ; gemacht, nur zum Testen, und danch lief das Script erst mal an, ohne eine Fehlermeldung auszuspucken, natürlich nur, bis entsprechende Klasse gebraucht wurde. Ich hab die Semikolons dann wieder weg gemacht und es ging immer noch - Bis jetzt, wo ich das Script erneut gestartet habe. Nun ist an einer anderen Stelle in der Datei mit den Klassen, wieder so ein Fehler aufgetreten.

Ich hab keine Idee mehr woran das noch liegen kann und wäre über eine Lösungsidee sehr glücklich.

PS:
Beide Scripte sind mit
# -*- coding: iso-8859-15-*-
kodiert.

[meneliel]

EDIT:

Der Fehler tritt NICHT auf, wenn ich das Script direkt laufen lasse/Syntax checke, sondern NUR, wenn mein Main-Script darauf zugreift.

[ws]

Sowas ähnliches habe ich auch schon gehabt, das war, wenn ich DOS-Zeilenumbrüche in UNIX-Dateien oder UNIX-Zeilenumbrüche in DOS-Dateien hatte. Interessant war daran, dass der Python-Interpreter sich beim Ausführen davon nicht verunsichern liess, sondern erst beim Import (durch nose-Testsuites) Probleme auftraten.

Ich würde erstmal folgendes Versuchen:
Überrprüfe mit einem Hexeditor auf dem Server und bei Dir lokal die Zeilenenden. DOS/Windows-Zeilen enden mit 0a 0d, UNIX-Zeilen nur mit 0a.

Wenn sich das Script, das die zu importierenden Klassen enthält, sich hier bei den Zeilenenden zwischen der Serverversion und Deiner lokalen Version unterscheidet, liegt hier wahrscheinlich der Fehler.
In diesem Fall wäre zu untersuchen, woher diese Abweichungen kommen. Es könnte sein, dass Dein Datentransferprogramm (ftp o.ä) diese Endungen austauscht. Das kannst Du umgehen, wenn Du Deine Datei packst (zip o.ä.), dann werden die von den Tools als Binärdateien nicht angefasst. Ein anderes Problem könnte sein, dass Du vielleicht ein Revisionsverwaltungssystem wie SVN oder so benutzt und unter UNIX/LINUX Windows-Sourcen ausgecheckt hast oder umgekehrt und der entsprechende EOL-Style nicht richtig auf "native" gesetzt wurde.

Vielleicht hilft das ja irgendwie weiter.

Gruss

Wolfgang

[meneliel]

Hallo Wolfgang,

Danke für deine Antwort. Beruhigend zu wissen, dass es noch anderen so ging.

Werde morgen lokal mal die Zeilenenden checken, aber da das ein Windowssystem ist, müsste auch dort 0a 0d sein.

Auf dem Server (Windowsserver), sind sie es jedenfalls immer noch korrekt, das hatte ich bereits gecheckt, weil ich vermutete, dass da wohl was nicht stimmt.

Kopiert habe ich die Daten via FTP. Nachdem das Problem auftrat, habe ich einfach eine leere Datei auf dem Server erstellt und über eine Remotedesktop Verbindung per Copy-Paste den Code dort eingefügt, mit dem gleichen Problem.

Ich hätte ja vermutet, dass vielleicht, aus irgendeinem Grund tatsächlich ein Fehler aufgetreten ist im Code, aber dann hätte lokal mein MyEclipse den Syntaxfehler ja schon finden müssen, dort läuft das Script aber fehlerfrei.

Seltsam ist auch, dass es ja nur eine handvoll Zeilen betraf.

Grüße
Maria

[Leonidas]

Nach dem Schnipsel was im Traceback vorkommt sieht es eher nach einem IndentationError aus. Kannst du die betreffende Datei mal ins Pastebin kopieren und hier verlinken?

[meneliel]

Ich bin mir ziemlich sicher, dass es KEIN Einrückungsfehler ist, weil
1. dürfte dann das Script nicht laufen, auch nicht lokal.
2. Müsste dann helfen, die Zeilen einfach neu anzuordnen und das tut es nicht (also zeilenumbruch löschen, alle Zeichen entfernen und dann Enter und zur Not per Tab an die richtige Stelle)
3. Wäre es dann ziemlich unlogisch, warum das Script ganz plötzlich, an Stellen wo es kein Problem gab und lief, bei einem nächste Aufruf erst den fehler findet.

So zum Beispiel gerade wieder. Lief jetzt mehrfach fehlerfrei durch. Jetzt habe ich ca. 100 Zeilen weiter oben im Script ein print eingefügt. Und bekomme nun wieder so einen Fehler. Gestern traten die Fehler auf, ohne, dass ich irgendwas im Script geändert habe.

Code: Alles auswählen

def create_special_array(self,html,x,y,user,n):
        ''' aus definierten Spalten die Liste für das Diagramm erstellen'''
        x_list = []
        y_list = []
        for element in html:
            if element[n] == user:
                x_list.append(element[x])
                y_list.append(element[y])
        return(x_list,y_list)

Traceback (most recent call last):
  File "x:\x\xx\Nutzerentwicklung.py", line 11, in ?
    import SQL_queries as SQL
  File "x:\x\xx\SQL_queries.py", line 254
            if element[n] == user:
                        ^
SyntaxError: invalid syntax
# Zeile 254 ist die mit dem for und nicht die mit dem if ...

BTW: die Stelle von gestern läuft jetzt, nachdem ich, einfache (wie meine Kollege das gemacht hatte, einfach nen Zeichen wie ; ans Ende der Zeile setzte, Script gestartet und gestoppt habe und das Zeichen wieder entfernt habe. Aber das kann ja keine Lösung sein ...

[Rebecca]

1. dürfte dann das Script nicht laufen, auch nicht lokal.

Wenn tabs und spaces zur Einrueckung verwendet werden und die beiden Python-Interpreter von unterschiedlichen Tab-Laengen ausgehen, schon. Also: Am besten immer nur Leerzeichen zum Einruecken verwenden.

Ansonsten wuerde ich wirklich mal, wie oben vorgeschlagen, die Datei gezipt oder sonstwie gepackt auf den Server kopieren, um sicher zu gehen, dass die Datei wirklich so erhalten bleibt, wie sie ist. Wenn du zwischen Linux und Windows kopierst, evtl. mal dos2unix bzw unix2dos drueberlaufen lassen, das konvertiert die Zeilenumbrueche.

[Y0Gi]

Zum Erkennen von gemischtem Whitespace (Spaces vs. Tabs, CRLF vs. LF vs. CR) kann ich SciTE als Editor empfehlen. Damit kann man sich diese (Trennzeichen und Zeilenumbrüche) separat anzeigen und konvertieren lassen.

Andere Editoren können sowas vermutlich auch, jedoch finde ich die im Quelltext angezeigten "Zeichen-Symbole" in SciTE sehr gelungen und ich schätze, dass zumindest vi da technisch bedingt nicht mitkommt (sofern da nicht was mit Unicode-Zeichen geht).

Dem Problem der Zeilenumbrüche kann man zudem mit den `dos2unix`-/`unix2dos`-Scripts zu Leibe rücken.

[Trundle]

Andere Editoren können sowas vermutlich auch, jedoch finde ich die im Quelltext angezeigten "Zeichen-Symbole" in SciTE sehr gelungen und ich schätze, dass zumindest vi da technisch bedingt nicht mitkommt (sofern da nicht was mit Unicode-Zeichen geht).

Könnte gut sein, dass das mit vi nicht geht, aber was kann vi schon? Aber es existiert gvim und in Terminals besteht durchaus die Möglichkeit, sich die Tabs in einer anderen Farbe darstellen zu lassen.