npyck python packer

Stellt hier eure Projekte vor.
Internetseiten, Skripte, und alles andere bzgl. Python.
Antworten
Manuelh87
User
Beiträge: 36
Registriert: Sonntag 15. März 2009, 16:24

Zuerst mal... PEP8... warum hab ich das nur nicht früher gelesen...
Werd versuchen mich da mehr drann zu halten, Code Standards sind (sofern sie nicht total häßlich sind wie in Java :P ) ne feine Sache und sollten natürlich eingehalten werden.

Dann nochmal zum zipfile: Also hab das jetzt abgeändert dass die Datei immer geschlossen wird da es nicht wirklich eine gute Möglichkeit gibt unter 2.5 besseren Zugriff auf das zipfile zu erzielen, ABER um es zu erklären warum ich die Datei NICHT schließen wollte: Die Idee war für 2.5 einfach eine Klasse zu machen die ein File Objekt emuliert. Das bringt für 2.5 nix, aber ich könnte dann nachsehen ob vielleicht ein 2.6 Interpreter läuft und dann die Datei mit geöffnetes_zip_file_objekt.open("datei_im_archiv", "r") öffnen. Sofern dieses wirklich besser implementiert ist und vielleicht nicht die gesamte Datei immer in den Speicher extrahieren muss (auch wenn ich das ein bisschen bezweifle, aber das galt es noch herauszufinden) hätte man mit dem file-like-object wesentliche Vorteile... NUR glaub ich nicht, dass man dann das geöffnetes_zip_file_objekt schließen darf... es gebe dann auch keine read Methode, sondern eine open Methode die ein file-like-object zurückgibt... ich hatte das für 2.6 bereits implementiert aber wieder verworfen bis auf weiters...

Aber da ich sowieso eher davon ausgehe, dass man hier bequem config files mitgeben kann, werden die ws. nicht unbedingt so extrem lang sein, dass man ruhig ein file.read() machen darf...

das __del__ war wohl wirklich Blödsinn... hab mir gedacht damit am Ende wenn der Interpreter beendet das zipfile geschlossen wird... es gibt hier wohl andere bessere Varianten ein sicheres schließen zu erzielen... z.b. try finally im "loader" code... falls ich das mit open doch mal implementiere, dann werd ich das wohl auf diese Weise machen...

Das return None sollte nur verdeutlichen dass das ein gewolltes Verhalten ist... mir ist klar dass es das Verhalten nicht ändert, aber es soll betonen, dass ich hier nicht einfach vergessen hab was zurückzuliefern, sondern hier tatsächlich None zurückliefern will...

Das mit except: find ich auch nicht so toll (code hat sich geändert), irgendwann such ich mir alle möglichen Exceptions die das zipfile Module werfen kann, bzw. die weitergereicht werden können heraus! Wenn jemand sie alle kennt, dann schreibt sie mir bitte dann ändere ich das sofort...
@Manuelh87: Das "zipfile" ist eine normale, geöffnete Datei, die Du immer schließen musst. Wenn Du das nicht tust, dann tut der Interpreter das zu einem nicht vorhersehbaren Zeitpunkt, oder das Betriebssystem, wenn der Prozess sich beendet.
> Entschuldige, aber das ist bitte nicht ganz richtig... nur wenige python Programme würden korrekt funktionieren wenn der Interpreter einfach irgendwann eine Datei schließen würde obwohl noch eine reference darauf gehalten wird... und sofern der User nicht del NPYCK_ aufruft halt ich die Reference bis zum bitteren ende... also kann er sie höchstens beim beenden schließen.. (Was natürlich unsauber ist, siehe oben wie ichs implementieren würde)

Um nochmal auf meine eigentliche Frage zurückzukommen:
Findet ihr das ganze sinnvoll? (Ich mein, keine Frage, Windows Support ist natürlich extrem wichtig, und ich bin drauf und drann mir was auszudenken... gehn wir mal davon aus es würde auf allen Platformen funktionieren) ich finde es hat vorallem Vorteile gegen python -m da es viel leichter für den Nutzer ist, und irgendwie find ichs auch angenehmer als Entwickler, da ich mein Projekt ganz normal als einzlne py Dateien rumliegen haben kann, schön testen kann, und danach einfach npyck mainfile.py -a -o pack.sh machen kann und das ganze verteilen kann...
Das Projekt muss halt auch darauf abgestimmt sein, aber ich finde das geht recht gut mit der NPYCK_ variable...

Noch etwas: Das Ganze ist eher quick&dirty entstanden, was nicht heißt dass es mir egal ist, aber wenn ich eines gelernt hab, dann lieber mal was Grobes schnell und vielleicht nicht extrem effizient implementieren, als gleich zu Anfang alles perfekt auszutüffteln wollen und niemals mit implementieren beginnen (hätte das ganze vielleicht eher in IDEEN oder so posten sollen...)
Soll aber nicht heißen dass die Verbesserungsvorschläge nicht extrem wertvoll für mich sind... vorallem dass ich mir die PEP endlich durchgelesen hab :) (Da gibts jetzt viel Code denn ich anpassen sollte...)

Nagut, ich hoffe es äußerst sich vielleicht auch noch wer über brauchbar/nicht brauchbar und bei nicht brauchbar vielleicht auch eine Begründung damit ich seh was das Problem ist...

Ansonsten hoff ich das der Stil sich verbessert hat (bis auf die except Sache zumindest) und keine Tabs drinnen sind (aber das sollt jetzt passen...)

@Hyperion: was meinst du mit
In Funktionsköpfen bitte keine Leerzeichen zwischen Operatoren
meinst du damit das:

Code: Alles auswählen

def bla(arg1, arg2, arg3)
oder das:

Code: Alles auswählen

def bla(arg1 = True, arg2 = False, arg3 = True)
bei dem '=' ?

das mit dem '=' hab ich in der neusten Version geändert.... wie gesagt PEP... :)
Wenn dich das mit den Beistrichen stört, dann muss ich sagen kann ich das nicht nachvollziehen...

Danke nochmal für die Beiträge.. :)
lunar

@Manuelh87: Wenn Du eine Datei nicht explizit schließt, dann wird sie natürlich erst geschlossen, nachdem die letzte Referenz verschwunden ist. Das ist aber doch eigentlich selbstverständlich.

Dennoch ist dann nicht definiert, wann die Datei tatsächlich geschlossen wird. Das Schließen wird in diesem Fall nämlich von __del__ übernommen, und das diese Methode problematisch ist, hast Du ja schon erkannt.

Ich würde auch nicht versuchen, alle Ausnahmen abzufangen. Fange die Ausnahmen ab, die Du sinnvoll behandeln kannst, und reiche den Rest mit Traceback an den Benutzer weiter.
Antworten