Das deutsche Python-Forum

Hallo, ich habe erst mal Windows 7 installiert, aber ein Programm, welches ich vorher unter XP geschrieben habe, geht nicht mehr. In den Programm verwende ich Optparse. ICh habe jetzt versucht mit der Windows 7 Konsole das Programm anzusprechen, aber es geht nicht. Weiß jemnad villeicht eine Lösung?? Würde mich sehr freuen.

MfG

cz3kit

Fehlermeldung? Code?

Ich kann den Code ma reinstellen, aber wie gesagt, unter Windows XP geht der Code, aber nicht unter Windows 7. http://paste.pocoo.org/show/139578/
Und Fehlermeldungen gibt es auch nicht.

@cz3kit: Warum stecken die ganzen Funktionen in einer Klasse?

Wie versuchst Du das zu starten? *Genau* bitte.

Ich starte das über die Windows Konsole z.B.
runlength.py -c -f test.bmp
und es ist alles in einer Klasse, weil es in der Aufgabe so ist, es ist eine schulische Aufgabe, ob es sinnvoll ist oder nicht, kann man sich drüber streiten
Es ist ja nicht das eigentliche Problem, es scheint einfach so das Optparse nicht mit Windows 7 kompatibel ist

@cz3kit: Und was passiert wenn Du das so eingibst? Fehlermeldung? Gar nichts? Woher weisst Du, dass es an `optparse` liegt? Was wird ausgeführt? Wo bricht die Ausführung ab? Was hast Du unternommen um das herauszufinden?

Das diese Klasse einen schlechten Namen hat und sinnlos ist, darüber kann man nicht streiten. Die Aufgabe wird sicher nicht gewesen sein das nur in eine Klasse zu stecken, sondern eine Klassen *sinnvoll* zu verwenden. Was sind denn hier die gemeinsamen Daten, auf denen die Methoden operieren? Und warum bindest Du so ziemlich alles als Attribut an das Objekt?

Was sollen die Kommentare mit den '-'-Linien die nur den folgenden Funktionsnamen enthalten? Das ist sinnlose Redundanz. Kommentare sollen dem Leser etwas sagen, was er nicht sowieso aus dem Quelltext schon problemlos ersehen kann.

In einer `__init__()`-Methode sollte ein Objekt initialisiert werden, so dass es danach in einem benutzbaren Zustand ist. Per Konvention sollten dort auch alle Attribute auf dem Objekt mit sinnvollen Werten belegt werden. Attribute, die erst in anderen Methoden eingeführt werden, machen Programme fehleranfälliger und schwerer zu lesen und zu verstehen, weil man nicht an einer Stelle sieht, welche Attribute es gibt, und die Existenz von Attributen von der Reihenfolge der Methodenaufrufe zur Laufzeit abhängt. Der Docstring der `__init__()` sagt nichts aus, was man ohne ihn nicht wüsste -- weg damit. Für Docstrings gilt dasselbe wie für Kommentare.

`RLed.quiet` ist ein Wahrheitswert, dafür sollte man nicht 0 und 1 missbrauchen, wo es `True` und `False` extra dafür gibt. Das Attribut wird weder inner- noch ausserhalb der Klasse verwendet, kann also weg.

Argumente sollte man nur `*file` nennen, wenn dort wirklich ein datei-ähnliches Objekt erwartet wird, bei dir werden aber keinen Dateien, sondern Datei*namen* erwartet.

Deine Ausnahmebehandlung ist durch die Bank weg unsinnig. Wenn Du sie da nicht hättest, würde Dir auch der Grund der Ausnahme ausgegeben. Und vor allem machst Du nach der Ausnahmebehandlung einfach mit der jeweiligen Operation weiter als wenn nichts gewesen wäre. Wenn ein `open()` mit einer Ausnahme fehlschlägt, macht es ja wohl nicht viel Sinn danach aus so einer nicht geöffneten Datei etwas zu lesen oder etwas hineinzuschreiben. Da kommt unweigerlich die nächste Ausnahme, die Du dann aber gar nicht behandelst. Der Benutzer bekommt also auf jeden Fall eine unbehandelte Ausnahme samt Stacktrace zu sehen, trotz Deiner "Ausnahmebehandlungen".

Namen komplett in GROSSBUCHSTABEN sind für Konstanten vorgesehen und Konstanten definiert man nicht bei jedem Funktionsaufruf und in verschiedenen Funktionen immer neu, sondern *einmal* innerhalb eines Programmlaufs, entweder auf Modulebene, oder zum Beispiel als Klassenattribut.

Und dann sollte man so eine Konstante auch konsequent *benutzen* und nicht über den ganzen Quelltext verstreut einen konstanten Wert doch wieder als literale "magische" Zahl schreiben. Und das auch noch mal in hexadezimaler und mal in dezimaler Schreibweise. Wer soll denn da den Überblick behalten. Wenn Du das mal von 0x90 auf etwas anderes umstellen möchtest, dann sollte der Quelltext so gestaltet sein, dass man den Wert an *genau einer Stelle* im Programm verändern muss. Sonst besteht die Gefahr, dass man bei so einer Änderung eine der vielen Stellen übersieht und das Programm dann defekt ist.

Warum ist der Docstring bei `expand()` auskommentiert?

`i` ist kein Name, den man für Zeichenketten verwenden sollte. Das ist ein typischer Name für eine "Zählvariable" bei der Programmierer eine ganze Zahl als Typ erwarten. Was da in `expand()` in der Schleife veranstaltet wird, ist alles andere als selbsterklärend. Da wäre ein Kommentar angebracht.

Explizite Vergleiche von Wahrheitswerten auf ``== True`` oder ``== False`` sind überlüssig und schlechter Stil. `os.path.isfile()` liefert schon einen Wahrheitswert, den braucht man nicht noch einmal mit `True` vergleichen, nur um wieder genau den gleichen Wahrheitswert zu erhalten.

Zum Trennen von Dateinamen und Erweiterung gibt es `os.path.splitext()`. Deine Methode fällt auf die Nase, wenn im Namen mehr als ein '.' enthalten ist.

In der Funktion wird der Ausgabedateiname an mehreren Stellen aufs Neue zusammengesetzt. Das kann man auch *einmal* machen, bevor man ihn das erste mal benötigt.

Die Funktion vermischt Programmfunktionalität mit Benutzerinteraktion, ist also nicht gut wiederverwendbar. Auch sollten Funtkionen nicht einfach mit `sys.exit()` das komplette Programm beenden. Das sollte einem sehr kleinen Programmteil vorbehalten bleiben, der ganz weit oben in der Aufrufhierarchie steht.

Die Namen `rled` und `bitmap` sind schlecht gewählt. Was soll ein `rled` sein? Ist das ein Kunstwort? Eine Abkürzung? `bitmap` ist schlecht gewählt, weil es viel zu einschränkend ist. Das ist ein allgemeiner Kompressionsalgorithmus, der funktioniert nicht nur mit Grafikdaten.

Was soll der Kommentar in Zeile 136? Ist das auskommentierter Quelltext? Dann weg damit. Soll das sagen, dass `self.num` eigentlich `self.number` heissen sollte? Dann umbenennen und weg mit dem Kommentar.

Das Dateiformat ist ungünstig aufgebaut. Erst sollten die Teile kommen, von denen die Länge in Bytes bekannt ist, also die Kennung und die Kompressionsart. Und dann erst die in der Länge variable Dateinamenserweiterung. Dann würde das Programm einfacher werden. Auch sollte die Kennung als Konstante definiert werden und nicht mehrfach im Quelltext als Zeichenkettenliteral auftauchen.

Das Dateiformat kommt übrigens nicht mit allen Dateinamen klar. Welche komplett ohne Endung und solche wo ein '>' in der Endung vorkommt, funktionieren mit dem Format nicht. Ersteres ist bei Textdateien gar nicht so selten.

In `compress_simple()` werden die Eingabedaten nicht überprüft. Das Programm sollte auch vernünftig reagieren, wenn der Benutzer eine Datei angibt, die nicht nur Bytewerte zwischen 0 und 127 enthält. So etwas machen Benutzer nämlich gerne -- sich nicht an die Anleitung halten. Sofern sie die überhaupt gelesen haben.

Einige Namen halten sich nicht an PEP8. Insbesondere mischt Du den empfohlenen Stil mit mixedCase. Man kann's ja gerne "falsch" machen, dann aber doch bitte konsequent.

`getCoding()` braucht Dokumentation und/oder einen besseren Namen. Ich dachte zuerst das soll die Kodierung von komprimierten Daten erraten, dabei ist die Funktion dazu da, um zu testen, ob man die "simple"-Komprimierung anwenden kann. 'komplex' und 'simple' sind auch wieder Kandidaten für Konstanten. Das Schliessen der Datei sollte man nur an einer Stelle der Funktion machen, hier würde sich ein ``try``/``finally`` anbieten. Oder ab Python 2.5 die ``with``-Anweisung. Bei 2.5 braucht man noch ein ``from __future__ import with_statement`` dafür -- ab 2.6 ist ``with`` auch ohne diesen Import ein Schlüsselwort der Sprache.

`getMethod()` ist so nicht besonders robust, wenn man weitere Verfahren einbaut. Es sollte explizit der Fall behandelt werden, bei dem eine unbekannte Kodierungsinformation in der Datei steht. Das, und auch eine fehlende Kennung sollten nicht mit "speziellen" Rückgabewerten, sondern mit Ausnahmen angezeigt werden. Und auch hier sollte man die Datei nur an einem Punkt schliessen.

Der Name `setExt()` ist wieder schlecht gewählt, weil man da erwarten würde, dass diese Methode nichts zurück gibt, sondern den Zustand des Objektes verändert, auf dem sie aufgerufen wird. Aber diese "Methode" ist ja auch gar keine, sondern eine Funktion die sinnlos in eine Klasse gesteckt wurde. Die Klammern beim ``return`` sind überflüssig, und der Code hat an der Stelle auch Probleme mit Dateinamen, die mehr als einen Punkt enthalten.

Bei "Setter"-Methoden erwartet man auch, dass sie einen Wert als Argument entgegenehmen, also `setStatusQuiet(self, value)`.

Der ganze Quelltext auf Modulebene ab ``#MAIN`` sollte in einer Funktion verschwinden. So hast Du immer noch unzählige Namen im Modul, die da nicht hingehören.

Die Funktionen enthalten zum Teil redundanten Quelltext, den man herausziehen sollte.

Du solltest überlegen aus all Deinen ``while``-Schleifen, bei denen Du davor einen Schritt tust um den Namen in der Abbruchbedingung zu initialisieren und die im Schleifenkörper den *gleichen* Schritt noch einmal enthalten in "Do-While"-Schleifen umzuwandeln, also in ``while True:``-Schleifen, die im Schleifenkörper eine Abbruchbedingen mit einer ``break``-Anweisung enthalten. Das ist für solche Schleifen idiomatischerer Code. Oder das ganze so umändern, dass man eine Funktion hat, die einen Iterator über Bytewerte liefert. Vielleicht auch mit einlesen der Daten in grösseren Blöcken. Für jedes Byte einzeln `file.read()` aufzurufen ist nämlich extrem ineffizient.

Den Bildschirm löschen, hat in Kommandozeilenprogrammen nichts zu suchen. Dafür werden Dich die Anwender verfluchen, weil sie da vielleicht noch wichtige Informationen stehen hatte, die Du ihnen einfach ungefragt weglöschst. Ausserdem sind ``os.system('cls')`` und das `msvcrt`-Modul windowsspezifisch. Du schränkst damit völlig unnötig das Betriebssystem auf Windows ein.

Es gibt einen Unterschied zwischen Optionen und Argumenten. Option kommt von optional, also etwas das man weglassen kann. Wenn man eine Option nicht weglassen kann, dann ist es semantisch keine Option mehr und man sollte es auch nicht also solche behandeln. Wenn der Benutzer angeben *muss* ob komprimiert oder dekomprimiert werden soll, oder er einen Dateinamen angeben *muss*, dann sind Optionen das falsche Mittel. Also entweder ist einer der beiden Modi die Voreinstellung und es wird ein Dateiname vorgegeben oder die Standardein/ausgabe verwendet, oder Du solltest die Benutzerschnittstelle überdenken.

@cz3kit: Und was passiert wenn Du das so eingibst? Fehlermeldung? Gar nichts? Woher weisst Du, dass es an `optparse` liegt? Was wird ausgeführt? Wo bricht die Ausführung ab? Was hast Du unternommen um das herauszufinden?

Ich öffne die Windows Konsole und gebe dann dort den Dateinamen ein und die benötigten Schalter, z.B. runlength.py -c(für compress) -f kirby.bmp(filenamen). Wenn ich dass mache, dann öffnet er mir nur den Editor mit dem Programmcode aber tut nichts weiter. Ich habe es heute noch in der Schule ausprobiert unter Windows XP und dort geht alles einwandfrei. Ich habe sogar schon die Umgebungsvariable von der Python.exe in die Konsole eingeführt, aber es geht dennoch nichts. Er zeigt mir keinen Fehler, nix, öffnet Editor das wars. Python Programme laufen an sich, aber ich habe dann später noch eine kleine test Datei geschrieben und da nur Optparse reingemacht und auch das ging nicht.

Das diese Klasse einen schlechten Namen hat und sinnlos ist, darüber kann man nicht streiten. Die Aufgabe wird sicher nicht gewesen sein das nur in eine Klasse zu stecken, sondern eine Klassen *sinnvoll* zu verwenden. Was sind denn hier die gemeinsamen Daten, auf denen die Methoden operieren? Und warum bindest Du so ziemlich alles als Attribut an das Objekt?

Ich weis nicht ob das deine Frage zum Teil beantwortet, aber das Programm soll nur über die Konsole und mit den Schaltern gesteuert werden, mehr erst mal nicht.

Was sollen die Kommentare mit den '-'-Linien die nur den folgenden Funktionsnamen enthalten? Das ist sinnlose Redundanz. Kommentare sollen dem Leser etwas sagen, was er nicht sowieso aus dem Quelltext schon problemlos ersehen kann.

Das Programm ist ja noch nicht fertig und die Striche sind für mich damit ich die Methoden schneller, z.B. beim Scrollen finden kann.

Deine Ausnahmebehandlung ist durch die Bank weg unsinnig. Wenn Du sie da nicht hättest, würde Dir auch der Grund der Ausnahme ausgegeben. Und vor allem machst Du nach der Ausnahmebehandlung einfach mit der jeweiligen Operation weiter als wenn nichts gewesen wäre. Wenn ein `open()` mit einer Ausnahme fehlschlägt, macht es ja wohl nicht viel Sinn danach aus so einer nicht geöffneten Datei etwas zu lesen oder etwas hineinzuschreiben. Da kommt unweigerlich die nächste Ausnahme, die Du dann aber gar nicht behandelst. Der Benutzer bekommt also auf jeden Fall eine unbehandelte Ausnahme samt Stacktrace zu sehen, trotz Deiner "Ausnahmebehandlungen".

Ich verstehe nicht so recht was du damit meinst.

Was soll der Kommentar in Zeile 136? Ist das auskommentierter Quelltext? Dann weg damit. Soll das sagen, dass `self.num` eigentlich `self.number` heissen sollte? Dann umbenennen und weg mit dem Kommentar.

Wie schon gesagt es noch nicht fertig und noch nicht kommentiert, das kommt ja noch.

In `compress_simple()` werden die Eingabedaten nicht überprüft. Das Programm sollte auch vernünftig reagieren, wenn der Benutzer eine Datei angibt, die nicht nur Bytewerte zwischen 0 und 127 enthält. So etwas machen Benutzer nämlich gerne -- sich nicht an die Anleitung halten. Sofern sie die überhaupt gelesen haben.

Genau für das Problem hab ich eine Methode, getCoding.

Du solltest überlegen aus all Deinen ``while``-Schleifen, bei denen Du davor einen Schritt tust um den Namen in der Abbruchbedingung zu initialisieren und die im Schleifenkörper den *gleichen* Schritt noch einmal enthalten in "Do-While"-Schleifen umzuwandeln, also in ``while True:``-Schleifen, die im Schleifenkörper eine Abbruchbedingen mit einer ``break``-Anweisung enthalten. Das ist für solche Schleifen idiomatischerer Code. Oder das ganze so umändern, dass man eine Funktion hat, die einen Iterator über Bytewerte liefert. Vielleicht auch mit einlesen der Daten in grösseren Blöcken. Für jedes Byte einzeln `file.read()` aufzurufen ist nämlich extrem ineffizient.

Hmm, das ist mir z.B. neu, aber man lernt ja nie aus

Den Bildschirm löschen, hat in Kommandozeilenprogrammen nichts zu suchen. Dafür werden Dich die Anwender verfluchen, weil sie da vielleicht noch wichtige Informationen stehen hatte, die Du ihnen einfach ungefragt weglöschst. Ausserdem sind ``os.system('cls')`` und das `msvcrt`-Modul windowsspezifisch. Du schränkst damit völlig unnötig das Betriebssystem auf Windows ein.

Oke gut zu wissen, das mit msvcrt ist mir z.B. auch neu das es Windows spezifisch ist.

Ich danke dir für die Hinweise und ich werde versuchen einen großen Teil davon umzusetzen, aber wie gesagt das eigentlich Problem ist ja leider nicht gelöst. Es geht einfach unter Windows 7 nicht und ich verstehe nicht warum. Ich meine das doch irgendwie eigenartig, unter XP geht alles wunderbar, aber nicht unter 7. Versteh ma einer die Welt.

Wie würdest du das eigentlich mit den Klassen machen, wiviele würdest du machen? Würdest du vielleicht ein Teil der Methoden als Funktionen machen?? Das würde mich mal interessieren, damit ich mir das ganze mal vorstellen kann, weil ich wüsste jetzt nicht wie ich das anders anstellen sollte, wäre dir dafür sehr dankbar.

Wenn ich dass mache, dann öffnet er mir nur den Editor mit dem Programmcode aber tut nichts weiter.

Das liegt daran, dass bei Dir anscheinend die Dateiendung ".py" eben mit dem Editor verknüpft ist und nicht mit dem Interpreter (python.exe). Verknüpf ".py"-Dateien wieder mit dem Interpreter, oder rufe die Datei explizit mit ihm auf (C:\Python\python.exe meinskript.py).

Zum besseren Verständnis: Wenn man einen Dateinamen auf der Eingabeaufforderung eingibt, so ist das in der Regel so, als würdest Du die Datei im Explorer öffnen (also z.B. per Doppelklick).

Generell ist ``python myscript.py`` eleganter, um solchen Problemen entgegen zugehen.

Das diese Klasse einen schlechten Namen hat und sinnlos ist, darüber kann man nicht streiten. Die Aufgabe wird sicher nicht gewesen sein das nur in eine Klasse zu stecken, sondern eine Klassen *sinnvoll* zu verwenden. Was sind denn hier die gemeinsamen Daten, auf denen die Methoden operieren? Und warum bindest Du so ziemlich alles als Attribut an das Objekt?

Wenn du eine Variable innerhalb einer Methode benötigst, aber nicht darüber hinaus, macht es keinen Sinn, sie an das Objekt (self) zu binden. Dein ``self.i`` brauchst du zum Beispiel nicht außerhalb und sollte deshalb nicht an das Objekt gebunden werden. (Der Sinn dieser Variable ist aber an sich schon diskussionwürdig.

Deine Ausnahmebehandlung ist durch die Bank weg unsinnig. Wenn Du sie da nicht hättest, würde Dir auch der Grund der Ausnahme ausgegeben. Und vor allem machst Du nach der Ausnahmebehandlung einfach mit der jeweiligen Operation weiter als wenn nichts gewesen wäre. Wenn ein `open()` mit einer Ausnahme fehlschlägt, macht es ja wohl nicht viel Sinn danach aus so einer nicht geöffneten Datei etwas zu lesen oder etwas hineinzuschreiben. Da kommt unweigerlich die nächste Ausnahme, die Du dann aber gar nicht behandelst. Der Benutzer bekommt also auf jeden Fall eine unbehandelte Ausnahme samt Stacktrace zu sehen, trotz Deiner "Ausnahmebehandlungen".

Beispiel:
Du fängst zwar den Fehler ab, trotzdem reagierst du nicht entsprechend darauf und machst einfach weiter. (Zeile 24)

Was soll der Kommentar in Zeile 136? Ist das auskommentierter Quelltext? Dann weg damit. Soll das sagen, dass `self.num` eigentlich `self.number` heissen sollte? Dann umbenennen und weg mit dem Kommentar.

Wie schon gesagt es noch nicht fertig und noch nicht kommentiert, das kommt ja noch.

Man sollte den Code eigentlich immer aufgeräumt halten.

@cz3kit: Das die Klasse nicht sinnvoll ist hat nichts damit zu tun, ob das ein Konsolenprogramm werden soll oder nicht. Es gibt einfach keine gemeinsamen Daten auf denen die "Methoden" operieren, das sind einfach nur ein Haufen Funktionen syntaktisch in eine Klasse gesteckt und alle möglichen Namen werden sinnlos an das Objekt gebunden.

Überleg Dir doch mal was bei Deiner Ausnahmebehandlung passiert. Wenn es zum Beispiel eine Datei gar nicht gibt, dann klappt das `open()` nicht, Deine Ausnahmebehandlung gibt eine entsprechende Meldung aus, Du machst aber trotzdem weiter! Das kann nicht funktionieren. Hast Du das überhaupt mal ausprobiert?

Beispiel:
Das `open()` schlägt fehl, und dann wird der Name `input_file` überhaupt gar nicht erst gebunden, die letzte Zeile versucht also auf einen Namen zurückzugreifen, der gar nicht existiert:
Okay, Du überprüfst mit `getCoding()` ob die Datei mit dem "simple"-Algorithmus komprimiert werden kann, aber ich hätte das trotzdem in der Kompressionsfunktion noch einmal überprüft. Die Datei kann sich ja bis dahin auch verändert haben, oder jemand versucht die Funktion ohne vorheriges Überprüfen der Eingabedaten aufzurufen. Dann gehen Daten verloren -- etwas was man bei einem allgemeinen Kompressionsprogramm normalerweise nicht haben möchte.

Ich wäre so eine Komprimierung wahrscheinlich erst einmal ohne Klassen, mit Generatorfunktionen angegangen, weil die sich bei so einem Algorithmus, der auf einem Strom von Werten arbeitet, irgendwie anbieten.

Wenn es unbedingt Klassen sein sollen, dann würde ich jeweils für das Komprimieren und Dekomprimieren eine einzelne, dateiähnliche Klasse implementieren, die das eigentliche schreiben und lesen an ein anderes dateiähnliches Objekt delegiert. Mindestens mit einer `put_byte()` bzw. einer `get_byte()`-Methode und darauf aufbauend dann eine `write()` bzw. `read()`-Methode. Dann kann man `shutil.copyfileobj()` verwenden, um die Daten von einer "Datei" in die andere zu kopieren. So dass Komprimieren dann zum Beispiel so aussehen kann:

cz3kit hat geschrieben:Das Programm ist ja noch nicht fertig und die Striche sind für mich damit ich die Methoden schneller, z.B. beim Scrollen finden kann.

Hmm, das klingt nach suboptimalem Editor. Code Folding und Ähnliches wird eigentlich von jedem besseren Editor unterstützt, siehe auch [wiki]Tags/Editoren[/wiki].

Was wäre denn wenn ich zwei Klassen mache, eine RL2 um Texte zu komprimieren, und einmal RL3 für Bitmaps etc.. In diese Klassen würde ich dann einfach ein paar Methoden schmeißen, um vielleicht den Header zu bestimmen. Außerhalb der Klassen dann noch einzelen Funktionen, um zu bestimmen, welche Klasse jetzt nun verwendet weerden soll. Das wäre jetzt eine Idee von mir, das umzubauen.Was haltet ihr da von??

Und sollte ich optparse ebenfalls in eine FUnktion tun? Eher nicht oder?

Der Teil nach ``if __name__ == '__main__':`` sollte sich auf main() o.ä. beschraenken.