UlZIP

[ulrich1992]

UliZIP ist ein plattformunabhängiger Archivierer der mit dem ZIP Industriestandard für komprimierte Dateien kompatibel ist und eine einfach zu benutzende grafische Oberfläche bietet.

Mein Ziel war es, meine allgemeine Codequalität zu verbessern und eine simple, auf den Punkt gebrachte, aber DAU-kompatible Oberfläche zu erstellen.

Für Windows existiert auch eine kompilierte *.exe Version.

Verwendet wurden Python 2.7.2, wxPython 2.8 und das in Python integrierte zipfile Modul


Hauptfenster unter Debian Linux:



Dateien hinzufügen unter Windows 7:



Hauptfenster unter Windows 7:



Und der Downloadlink:
http://www.deruli.de/seite/ulizip

[lunar]

@ulrich1992: Nun, ZIP-Programme gibt es wie Sand am Meer, insofern sehe ich den Sinn in Deinem nicht so wirklich. So wirklich „DAU-kompatibel“ ist es auch nicht, dem Nutzer ein ZIP_DEFLATED vorzusetzen…

Zum Quelltext: "unicode()" direkt auf Dateinamen anzuwenden, funktioniert nicht für Dateinamen außerhalb des ASCII-Bereichs. Konkret wirft Dein Quelltext eine Ausnahme, wenn der Benutzername einen Umlaut enthält. Dateinamen musst Du mit "sys.getfilesystemencoding()" dekodieren.

Für temporäre Dateien gibt es das "tmpfile"-Modul, welches Du in diesem Fall verwenden solltest. Nutzer werden es Dir danken, wenn beim möglichen Absturz Deines Programms kein merkwürdiges "tmp"-Verzeichnis im Heimatverzeichnis zurückbleibt. Zudem kannst Du Dir das Löschen am Ende sparen, das erledigt dann das Betriebssystem.

Globale Konstanten wie etwa "wildcard_for_documents" sollten nach PEP 8 durchgehend groß geschrieben werden, damit sie auch als Konstanten zu erkennen sind.

"number_format()" ist überflüssig und kann durch "locale.format" aus der Standardbibliothek ersetzt werden.

Globale Variablen wie in "createnewFile" (merkwürdige Groß/Kleinschreibung, btw) sind ein No-Go. Nutze Klassen und Klassenattribute.

Die Datumsformatierung in "ListFiles()" ist viel zu kompliziert, nutze die Möglichkeiten des "datetime"-Moduls aus der Standardbibliothek.

Das ist mir beim Überfliegen so aufgefallen. Auch solltest Du auf konsistentere Benennung und Formatierung des Quelltexts achten. An manchen Stellen sind mitten in einem Ausdruck auf einmal mehrere Leerzeichen zu finden, an anderen Stellen dagegen überhaupt keine. Das erschwert das Lesen Deines Quelltexts.

[jens]

@ulrich1992: Wäre IMHO besser dein Quellentext würde in einem öffentlichen zugänglichen Versionsverwaltung stecken. (Ich mag nicht erst ein Archiv downloaden/entpacken um im Code rum zu schnüffeln). Ich würde dir github empfehlen

Für mich persönlich würde das ganze nur Sinn machen, wenn 7zip unterstützt würde. Dafür gibt es auch http://www.joachim-bauch.de/projects/pylzma/ Wobei ich mir dem 7zip mitgelieferten GUI gut auskomme... Allerdings nur für Windows... Was Programmunabhängiges (bzw. Alternative zu Fileroller für Linux) wäre nett...

An manchen Stellen sind mitten in einem Ausdruck auf einmal mehrere Leerzeichen zu finden, an anderen Stellen dagegen überhaupt keine. Das erschwert das Lesen Deines Quelltexts.

Sowas nimmt mit Eclipse ab, das Formatiert automatisch den Quellentext...

[ulrich1992]

@ulrich1992: Nun, ZIP-Programme gibt es wie Sand am Meer, insofern sehe ich den Sinn in Deinem nicht so wirklich.

Was wäre denn ein sinnvolles Softwareprojekt? Es gab doch alles in der Geschichte des Computers schon einmal.

So wirklich „DAU-kompatibel“ ist es auch nicht, dem Nutzer ein ZIP_DEFLATED vorzusetzen…

Welche Auswahl wäre denn an dieser Stelle DAU-Kompatibel?
Die Standardkompressionsmethode für Zip heißt nun mal Deflating.
Bei 7-ZIP kann man auch nur zwischen Deflate, Deflate 64, BZip2, LZMA und PPMd wählen. Was dem Nutzer der das ZIP-Format nicht kennt auch nicht mehr als ZIP_DEFLATED sagt.
Wenn man sich nicht vorher über Kompressionsalgorhythmen informieren möchte, nimmt man halt die Voreinstellung. Ist ja bei anderer Software auch nicht anders.

Zum Quelltext: "unicode()" direkt auf Dateinamen anzuwenden, funktioniert nicht für Dateinamen außerhalb des ASCII-Bereichs.

Wenn ich den Dateinamen nicht vorher in einen Unicode-String konvertiere, wirft er mir sobald ich den Dateinamen in der GUI ausgeben möchte einen UnicodeError.
Dateinamen mit Umlauten machen zumindest auf meinem System keine Probleme.

Für temporäre Dateien gibt es das "tmpfile"-Modul, welches Du in diesem Fall verwenden solltest. Nutzer werden es Dir danken, wenn beim möglichen Absturz Deines Programms kein merkwürdiges "tmp"-Verzeichnis im Heimatverzeichnis zurückbleibt. Zudem kannst Du Dir das Löschen am Ende sparen, das erledigt dann das Betriebssystem.

Ich möchte aber keine temporäre Dateien mit irgendwelchen zufällig generierten Buchstabenkombinationen als Name. Die temporären Dateien sollten Ihren ursprünglichen Namen behalten.
Sonst würde Windows auch meckern, weil die Datei keine Endung hat.

Globale Konstanten wie etwa "wildcard_for_documents" sollten nach PEP 8 durchgehend groß geschrieben werden, damit sie auch als Konstanten zu erkennen sind.

Beim schreiben des Namens habe ich gar nicht daran gedacht, dass das eine Konstante sein soll. Für mich ist das eine ganz normale Variable.
Soweit ich weiß gibt es in Python auch gar keine Konstante wie beispielsweise in Java.

"number_format()" ist überflüssig und kann durch "locale.format" aus der Standardbibliothek ersetzt werden.

Die Funktion kannte ich nicht.

Globale Variablen wie in "createnewFile" (merkwürdige Groß/Kleinschreibung, btw) sind ein No-Go. Nutze Klassen und Klassenattribute.

Klassen sind bei so einem kleinen Projekt Schwachsinn.
Ich wüsste gar nicht wie ich die nennen soll.
Eine Klasse "gui" und eine Klasse "zip_functions" oder wie?
Und dann auch noch für alles mögliche getter und setter Methoden bauen.
Das dauert viel zu lange.
Da hab ich mit prozeduraler Programmierung wesentlich schneller vorzeigbare Ergebnisse.

Die Datumsformatierung in "ListFiles()" ist viel zu kompliziert, nutze die Möglichkeiten des "datetime"-Moduls aus der Standardbibliothek.

Das wollte ich erst benutzen, aber das erwartet als Format eine Liste mit 9 Elementen .
stat.st_mtime gibt aber eine Liste mit 6 Elementen zurück.
Ich habe zumindest keine eingebaute Funktion gefunden um das zu konvertieren.

[ulrich1992]

An manchen Stellen sind mitten in einem Ausdruck auf einmal mehrere Leerzeichen zu finden, an anderen Stellen dagegen überhaupt keine. Das erschwert das Lesen Deines Quelltexts.

Sowas nimmt mit Eclipse ab, das Formatiert automatisch den Quellentext...

Eclipse ist aber eine Entwicklungsumgebung für Java.
Das bringt mir bei Python-Code nicht viel.

[EyDu]

Eclipse ist aber eine Entwicklungsumgebung für Java.
Das bringt mir bei Python-Code nicht viel.

Eclipse ist eine Entwicklungsumgebung für alle möglichen Sprachen. Für Python ist zum Beispiel das Plugin PyDev recht verbreitet.

[ulrich1992]

Eclipse ist aber eine Entwicklungsumgebung für Java.
Das bringt mir bei Python-Code nicht viel.

Eclipse ist eine Entwicklungsumgebung für alle möglichen Sprachen. Für Python ist zum Beispiel das Plugin PyDev recht verbreitet.

OK, das kannte ich nicht.
hab meine Source Codes bisher immer mit einem plain Texteditor geschrieben.

[jens]

Was ich meine ist Window -> Preferences -> Pydev -> Editor -> Code Style -> Code Formatter:


Ich verwende Aptana Studio: http://www.aptana.com/products/studio3 Was es entweder als Erweiterung für Eclipse gibt, oder als eigenständiger Download. Da ist für mich direkt alles dabei, was ich ansonsten in Eclipse "nachinstallieren" muß...

Die Diskussion darüber könnte man aber bei http://www.python-forum.de/viewtopic.ph ... 72#p197272 weiterführen...


Zu 'Tempfile' es gibt auch sowas wie NamedTemporaryFile

[lunar]

@jens: Wenn ich mich richtig erinnere, gibt es die von Windows bekannte 7zip-Oberfläche mittlerweile auch für Linux.

@ulrich1992: „DAU-kompatibel“ wäre es, erst gar keine Auswahl anzubieten, sondern einfach immer den bestmöglichen zu nutzen. Oder die Auswahl zumindest nicht basierend auf irgendwelchen technischen Begriffen, sondern auf den Vor- und Nachteilen der einzelnen Algorithmen anzubieten (e.g. eine Checkbox "[ ] schlechtere Komprimierung zugunsten alter Packprogramme"). Der Sinn einer Oberfläche ist es auch, die technischen Aspekte verständlich darzustellen.

Die Dateinamen musst Du natürlich in einen "unicode"-String konvertieren, aber eben nicht mit "unicode()", sondern mit ".decode(sys.getfilesystemencoding())". Falls Dir der Unterschied nicht klar ist, dann informiere Dich bitte über Textkodierungen und deren Umsetzung in Python.

Wenn Du Dir die API des "tempfile"-Moduls ansiehst, so erkennst Du, dass Du mit "tempfile.mkdtemp()" ein temporäres Verzeichnis anlegen kannst. In diesem Verzeichnis kannst Du dann beliebige Dateien mit beliebigen Namen erzeugen. So wie Du temporäre Dateien jetzt behandelst, ist das Programm einfach nur kaputt, unter anderem schon, weil sich zwei gleichzeitig laufende Exemplare Deines Programms auf dasselbe temporäre Verzeichnis zugreifen, und sich somit gegenseitig in die Quere kommen.

Es ist richtig, dass es in Python keine echten Konstanten gibt (in Java im Übrigen auch nicht). Allerdings gibt es in jedem Programm Objekte, die semantisch konstante Werte enthalten (wie eben die erwähnte Liste der Dokument-Typen). Diese sollten zwecks Lesbarkeit durch entsprechende Namenskonventionen gekennzeichnet werden, PEP 8 empfiehlt dazu eben durchgehende Großschreibung.

In Deinem Programm – allgemein in jedem GUI-Programm – sind Klassen nie Schwachsinn. Die Verwendung globaler Variablen ist Schwachsinn. Im Endeffekt hast Du bereits eine Klasse, weil Du mittels "global" Dein Modul als Klasse missbrauchst, mit dem Effekt, dass man die Verwendung von "filename" in den verschiedenen Funktionen nicht mehr nachvollziehen kann. Eine sinnvolle Klasse wäre beispielsweise eine, welche die Funktionalität des Hauptfensters kapselt. Du musst auch keine Getter und Setter implementieren, Python ist nicht Java. Mag sein, dass Du mit prozeduraler Programmierung schneller bist, aber dementsprechend sieht Dein Quelltext auch aus: Nach einem schnell dahin geschriebenen Wust.

Ein Modul wie "datetime" nimmt keine Argument entgegen. Was also erwartet neun Elemente? Was soll "stat.st_mtime" sein? Im Zusammenhang mit der kritisierten Zeile kommt überhaupt kein "stat" vor. Stattdessen geht es um "zipfile.ZipInfo.date_time", und wenn man sich die Dokumentation dazu ansieht, dann sind da offensichtliche Parallelen zu "datetime.datetime". So offensichtlich, dass jeder Narr auf "datetime.datetime(*entry.date_time)" kommen sollte…

[ulrich1992]

Ein Modul wie "datetime" nimmt keine Argument entgegen. Was also erwartet neun Elemente? Was soll "stat.st_mtime" sein? Im Zusammenhang mit der kritisierten Zeile kommt überhaupt kein "stat" vor. Stattdessen geht es um "zipfile.ZipInfo.date_time", und wenn man sich die Dokumentation dazu ansieht, dann sind da offensichtliche Parallelen zu "datetime.datetime". So offensichtlich, dass jeder Narr auf "datetime.datetime(*entry.date_time)" kommen sollte…

Stimmt hast recht.
Ich hatte da was verwechselt.
Ich hatte versucht das Änderungsdatum durch time.localtime() durchzujagen, weil ich dachte, da käme ein Timestamp als raus.
Das ging nicht.
Dann habe ich gemerkt, das da eine Liste bei heraus kommt, die die einzelnen Datumselemente enthält und dann damit einfach einen String zusammen gesetzt.

Ich hätte mir da in der Doku vom zipfile Modul statt dem Satz "This is a tuple of six values" sowas wie "This is an object from type datetime.datetime" gewünscht.
Dann hätte ich mir wohl eher die Doku vom datetime Modul angesehen und das Modul verwendet.

Ein "tuple of six values" kann alles mögliche sein.
Woher soll ich da auf das datetime Modul kommen?

[lunar]

@ulrich1992: Nun, da dieses Attribut eben kein Datumsobjekt ist, liegt es doch nahe, es in ein richtiges Datumsobjekt umzuwandeln, um es weiter zu verarbeiten.