Hi!
Ich mal wieder mit meinen packern... vielleicht erinnert sich ja noch jemand an die pypack idee (darf ich das einfach mit nem fixen link verknüpfen, oder gibts da andere möglichkeiten??)
Die war recht schlecht... Hab aber irgendwann mal wieder so eine Idee gehabt und mit ein paar tips aus dem forum verbunden...
so entstand npyck... es ist leider noch sehr häßlich programmiert, aber wenn es als nützlich erachtet wird, dann geb ich mir Mühe..
Die Idee: alles schön mit optparse unix mäßig machen und die shellskript vor zip datei variante umsetzten... Zusätzlich soll es möglich sein, z.b. Datein aus dem zip archiv zu lesen.. (gern würd ich auch überschreiben, aber das ist mit Problemen verbunden...)
In Moment hab ich eine Version, wo der "loader" code in eine zeile geht (hat mit dem Versuch Windows zu unterstüzten zu tun...) und im zip file alle source datein sind, plus das npyck utility... es schippt sich also immer selbst mit, damit so dinge wie auf dateien innerhalb vom zip zugegriffen werden kann...
Hier http://pfrinc.pf.funpic.de/npyck/test.zip ist eine Zip Datei mit sinnlosen Testskripts (wollt nur schauen wie das mit dem top-environment ist, die tun nichts böses). Man kann sie einfach entpacken, oder, mit nem terminal ausführen... die npyck.py ist auch dabei.
Ich hoffe es ist wenigstens ein bisschen brauchbar... npyck ist hoffentlich dank optparse selbsterklärend...
npyck python packer
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Ich weiß jetzt ehrlich gesagt nicht, wovon Du redest! Wieso verlinkst Du den Thread nicht? Ist doch sinnvoll.
Also ich habe keine Lust mir eine "dubiose" zip-Datei von irgend wo zu ziehen. Ist das Script denn so umfangreich, dass es ein paste-bin nicht getan hätte?
Alternativ eben als Repository bei github, bitbucket o.ä.
Wenn Du schon selber sagst, dass es häßlich ist, erwartest Du dann ernsthaft, dass diese Aussage jemanden motiviert, sich das anzugucken? Anscheinend ist es Dir selber ja nicht so wichtig, es sauber anzugehen...
Also ich habe keine Lust mir eine "dubiose" zip-Datei von irgend wo zu ziehen. Ist das Script denn so umfangreich, dass es ein paste-bin nicht getan hätte?
Alternativ eben als Repository bei github, bitbucket o.ä.
Wenn Du schon selber sagst, dass es häßlich ist, erwartest Du dann ernsthaft, dass diese Aussage jemanden motiviert, sich das anzugucken? Anscheinend ist es Dir selber ja nicht so wichtig, es sauber anzugehen...
Wieso verlinkst Du den Thread nicht? Ist doch sinnvoll
Noch Fragen? Ich kann ja nicht wissen wie das hier implementiert ist... bin ich Hellseher, deshalb frag ich ja! Hier der link: http://www.python-forum.de/topic-18173.htmldarf ich das einfach mit nem fixen link verknüpfen, oder gibts da andere möglichkeiten
Was soll ich da sagen... Dann lass es..Also ich habe keine Lust mir eine "dubiose" zip-Datei von irgend wo zu ziehen
Man kann hier scheinbar nix hochladen, also hab ich ne schnelle lösung gesucht... Ich hab ja erklärt worum es sich handelt... es ist ein zip und davor ist ein shell skript... also das skript einfach mit nem text editor lesen (hab sogar geschrieben was da im prinzip steht) und das zip file zu entpacken sollte kein problem darstellen.
Ja! Hab ich extra brav ausprobiert... zuerst dacht ich mir: "passt schon, einfach einfügen" Aber habs extra ausprobiert und war schon so 2 a4 seiten oder so, und dann dacht ich mir "nein da werd ich gschimpft, wenn ich das forum zukleister mit code"Ist das Script denn so umfangreich, dass es ein paste-bin nicht getan hätte?
ja, wenn es irgend jemand als brauchbar deklariert dann kümmer ich mich darum... aber das ordentlich zu machen ist arbeit... wenn es hier niemand nützlich findet dann werd ichs trotzdem irgendwann raufstellen... irgendwann... aber wenn das hier Anklang findet dann beeil ich mich... sonst dauerts halt noch... (Dazu kommt dass ich nur schön kommentierten Code der effizient ist bei github veröffentlichen will und nicht alles... da hab ich nunmal gewisse Ansprüche... das ganze ist halt Aufwand, den ich nicht nur für mich anstellen will... zumindest nicht so bald da ich mit der jetztigen version sehr zufrieden bin...)Alternativ eben als Repository bei github, bitbucket o.ä.
Okay, wenn ich schreib mein Code ist häßlich, dann ist das ein bisschen übertrieben, dass heißt nur er ist nicht ganz schön hergerichtet und vollständig getestet... Aber ich will ja in erster linie dass jemand der interessiert ist, einfach mal das programm ausprobiert, es einfach nutzt... dazu muss er nicht am Code weiterarbeiten... einfach nur ausprobieren und schaun obs brauchbar ist... vielleicht alte python projekte die aus vielen dateien bestehen probiern ob sie als zip ausführbar sind, obs fehler gibt... ka.Wenn Du schon selber sagst, dass es häßlich ist, erwartest Du dann ernsthaft, dass diese Aussage jemanden motiviert, sich das anzugucken? Anscheinend ist es Dir selber ja nicht so wichtig, es sauber anzugehen...
Das ganze war nur ein Versuch dem Forum und Entwicklern allgemein mal etwas zurückzugeben... ich hab versucht die Ideen aus dem ersten Thread umzusetzen, und ich glaub es ist ein schlankes brauchbares Tool geworden. Die Idee dahinter war ein einfach auszuführendes packet zu schaffen, dass man auf verschiedenen platformen starten kann (lassen wir mal windows beiseite... aber das muss natürlich auch unterstützt werden) es ging mir vorallem um OSX, nicht weil das so unglaublich toll wäre, sonder gerade weil man unter OSX ziemlich probleme als anwender hat python code komfortabel zu starten (meines erachtens liegt das an dem ach so intuitiv zu bedienenden finder, mit dem es einem fast unmöglich gemacht wird mit python komfortabel als anwender zu arbeiten) Vielleicht gibt es bessere Möglichkeiten, ich werd mir sicher keinen Mac kaufen um sie zu finden und da man OSX ja nur so starten kann weil es ja nur eine Handvoll an Komponenten unterstützt und auch rechtlich garnicht erlaubt ist es auf nicht apple hardware zu starten.....
Das Packet lässt sich auf einem Mac von Usern recht leicht startbar machen... relativ zumindest... Außerdem gefällt mir die Idee generell (sie kommt bitte nicht von mir...)
mfg Manuel
-
BlackJack
@Manuelh87: Erklärt worum es sich handelt hattest Du nicht wirklich. Da hätte man entweder Deinen alten Beitrag suchen müssen, oder sich die Datei herunterladen müssen.
A4 Seiten sind keine besonders zuverlässige Angabe über den Umfang von Quelltexten. Das hängt ja ganz entscheident von Schriftgrösse, Kopf- und Fusszeilen, und Layout auf einem Blatt an. Wenn damit 120 bis 132 Zeilen gemeint sind, die könnte man noch Problemlos in einem Paste-Bin abladen und dann hier verlinken.
Du entwickelst etwas für eine Plattform, die Du gar nicht besitzt? IMHO keine gute Idee. Wie testest Du dann?
A4 Seiten sind keine besonders zuverlässige Angabe über den Umfang von Quelltexten. Das hängt ja ganz entscheident von Schriftgrösse, Kopf- und Fusszeilen, und Layout auf einem Blatt an. Wenn damit 120 bis 132 Zeilen gemeint sind, die könnte man noch Problemlos in einem Paste-Bin abladen und dann hier verlinken.
Du entwickelst etwas für eine Plattform, die Du gar nicht besitzt? IMHO keine gute Idee. Wie testest Du dann?
Pastebin != Code-TagsManuelh87 hat geschrieben:Ja! Hab ich extra brav ausprobiert... zuerst dacht ich mir: "passt schon, einfach einfügen" Aber habs extra ausprobiert und war schon so 2 a4 seiten oder so, und dann dacht ich mir "nein da werd ich gschimpft, wenn ich das forum zukleister mit code"Ist das Script denn so umfangreich, dass es ein paste-bin nicht getan hätte?
Pastebin = (z.B) http://paste.pocoo.org
the more they change the more they stay the same
Sry, paste-bin kannte ich nicht. Ich versteh aber ehrlich gesagt auch nicht warum das DIE einzig erlaubte form ist, andere an Code teilhaben zu lassen.. und warum meine Variante so schlecht ist.
Wegen den a4 seiten: Nehmt bitte nicht alles so wörtlich, ich habs nicht abgemessen, und mir ist auch klar dass man auch nur einen Buchstaben auf eine A4 Seite schreiben kann... Trotzdem glaub ich kann man sich mehr unter einer a4 seite code vorstellen, als 132.5 zeilen... ganz ehrlich... ich programmier häufig, und zeilennummern sind meine freunde (bei fehlern etc), aber wenn du mir sagst "der code ist 200 zeilen lang", kann ich mir nichts darunter vorstellen... sry.. aber ich denk auch dass ist ansichtssache...
Aber ich nehm eure vorschläge gerne an, wenn das hier so wichtig ist. Also: der Code hat 149 Zeilen Code.. wo darf ich den jetzt hinmachen damit ihn vielleicht endlich mal jemand ansieht, und wir nicht nur darüber diskutieren was ich alles bei meinem Post falsch mache... (Nicht dass das unwichtig wäre, aber es geht eigentlich um npyck)
(Das mit OSX war vielleicht auch ein bisschen missverständlich. Erstens ist es nicht so dass ich nicht die Möglichkeit hab ein program zu testen auf einem mac... ich besitze nur keinen... Zweitens gibt es gute Python dokus, wo man gewöhnlich erfährt, ob was auf einer platform unterstüzt ist oder nicht... außerdem ist es nur aus der Not heraus entstanden, das heißt ja nicht dass es nur auf mac abzielt... )
Nehmt mir meine Laune bitte nicht übel, aber das letzte mal hat das so gut funktioniert, und ich hab wirklich wertvolle Tipps erhalten und das hat mich sehr gefreut und war äußerst produktiv. Und ich hab mir Mühe gegeben diese Dinge umzusetzen...
Aber ich hab das Gefühl kein einziger hat sich das tool überhaupt angesehen... und damit mein ich ausprobiert... ist ja auch okay, ich kann ja keinen zwingen es interessant zu finden, aber trotzdem gehts hier in dem Beitrag um npyck. Schickt mir von miraus eine private Nachricht um mir zu erklären was ich beim posten alles falsch mache, ich nehm die kritik gerne an (auch wenns vielleicht nicht den Eindruck macht) aber sie tut nichts zum Thema...
Wegen den a4 seiten: Nehmt bitte nicht alles so wörtlich, ich habs nicht abgemessen, und mir ist auch klar dass man auch nur einen Buchstaben auf eine A4 Seite schreiben kann... Trotzdem glaub ich kann man sich mehr unter einer a4 seite code vorstellen, als 132.5 zeilen... ganz ehrlich... ich programmier häufig, und zeilennummern sind meine freunde (bei fehlern etc), aber wenn du mir sagst "der code ist 200 zeilen lang", kann ich mir nichts darunter vorstellen... sry.. aber ich denk auch dass ist ansichtssache...
Aber ich nehm eure vorschläge gerne an, wenn das hier so wichtig ist. Also: der Code hat 149 Zeilen Code.. wo darf ich den jetzt hinmachen damit ihn vielleicht endlich mal jemand ansieht, und wir nicht nur darüber diskutieren was ich alles bei meinem Post falsch mache... (Nicht dass das unwichtig wäre, aber es geht eigentlich um npyck)
(Das mit OSX war vielleicht auch ein bisschen missverständlich. Erstens ist es nicht so dass ich nicht die Möglichkeit hab ein program zu testen auf einem mac... ich besitze nur keinen... Zweitens gibt es gute Python dokus, wo man gewöhnlich erfährt, ob was auf einer platform unterstüzt ist oder nicht... außerdem ist es nur aus der Not heraus entstanden, das heißt ja nicht dass es nur auf mac abzielt... )
Nehmt mir meine Laune bitte nicht übel, aber das letzte mal hat das so gut funktioniert, und ich hab wirklich wertvolle Tipps erhalten und das hat mich sehr gefreut und war äußerst produktiv. Und ich hab mir Mühe gegeben diese Dinge umzusetzen...
Aber ich hab das Gefühl kein einziger hat sich das tool überhaupt angesehen... und damit mein ich ausprobiert... ist ja auch okay, ich kann ja keinen zwingen es interessant zu finden, aber trotzdem gehts hier in dem Beitrag um npyck. Schickt mir von miraus eine private Nachricht um mir zu erklären was ich beim posten alles falsch mache, ich nehm die kritik gerne an (auch wenns vielleicht nicht den Eindruck macht) aber sie tut nichts zum Thema...
Ich kann mir unter X Zeilen Code mehr vorstellen
Code -> http://paste.pocoo.org, dann sieht man sich den Code auch an
Code -> http://paste.pocoo.org, dann sieht man sich den Code auch an
the more they change the more they stay the same
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Ist es nicht - aber es ist nun einmal verdammt einfach, weil man dann sofort mit einem Klick den Code sieht und seinen Rechner nicht mit Dateien zu müllt, von denen man nicht einmal den Inhalt kennt. Übertrieben gesagt: Wer weiß, was Du in diese Datei alles reingepackt hast?Manuelh87 hat geschrieben:Sry, paste-bin kannte ich nicht. Ich versteh aber ehrlich gesagt auch nicht warum das DIE einzig erlaubte form ist, andere an Code teilhaben zu lassen.. und warum meine Variante so schlecht ist.
Also da wird Dir hier so ziemlich jeder widersprechen! Anzahl Code Zeilen sagt einem schon mehr als Din-A4 Seiten - so oft drucke ich keinen Code aus, um auch nur im Ansatz zu wissen, was bei einer akzeptablen Schriftgröße so alles auf eine Seite passt. Ist natürlich kein zentrales Problem, aber als generelle Einschätzung sicherlich auch für Dich zukünftig nützlich. Wir können aber auch offtopic gerne mal eine Abstimmung startenWegen den a4 seiten: Nehmt bitte nicht alles so wörtlich, ich habs nicht abgemessen, und mir ist auch klar dass man auch nur einen Buchstaben auf eine A4 Seite schreiben kann... Trotzdem glaub ich kann man sich mehr unter einer a4 seite code vorstellen, als 132.5 zeilen... ganz ehrlich... ich programmier häufig, und zeilennummern sind meine freunde (bei fehlern etc), aber wenn du mir sagst "der code ist 200 zeilen lang", kann ich mir nichts darunter vorstellen... sry.. aber ich denk auch dass ist ansichtssache...
paste.pocoo.org ist hier sehr beliebt!Aber ich nehm eure vorschläge gerne an, wenn das hier so wichtig ist. Also: der Code hat 149 Zeilen Code.. wo darf ich den jetzt hinmachen damit ihn vielleicht endlich mal jemand ansieht, und wir nicht nur darüber diskutieren was ich alles bei meinem Post falsch mache... (Nicht dass das unwichtig wäre, aber es geht eigentlich um npyck)
Genau das kommt imho aus dem ersten Post nicht so rüber! Daher habe ich Dich ja gerade auf suboptimale Passagen aus deiner Ankündigung aufmerksam gemacht, damit sich die Leute Deinen Code angucken!Und ich hab mir Mühe gegeben diese Dinge umzusetzen...
Und genau das liegt u.a. sicherlich an der wenig beliebten Download-VarianteAber ich hab das Gefühl kein einziger hat sich das tool überhaupt angesehen... und damit mein ich ausprobiert...
Und verstärkt sicherlich auch an Aussagen a la "es ist leider noch sehr häßlich programmiert, aber wenn es als nützlich erachtet wird, dann geb ich mir Mühe".Ich wette aber, dass Du Feedback bekommst, wenn Du es in ein paste-bin postest, oder eben auch ein Repository bei github oder bitbucket anlegst (denn da kann man auch bequem per Browser Quellcode angucken).
Okay okay... überzeugt... http://paste.pocoo.org/show/195278/
und hier ein kleines testprogram um zu sehen was man damit treiben kann... http://paste.pocoo.org/show/195283/
einfach als test.py abspeichern und mit ./npyck.py test.py -o pack.sh bearbeiten und schon ist das packet erstellt und ausführbar...
Nochmal: Häßlich bezieht sich auf die Namen der Funktionen und Objekte... Aber der Code sollte soweit klar sein dass man sieht dass er nix böses tut, und dann kann man ihn ja einfach mal ausprobieren...
Und das ganze kommt bald auf git, ich bin ja auch total überzeugt von git und es wird ja schon damit entwickelt... ich muss nur noch vielleicht einen besseren Namen wählen und gewisse Unschönheiten entfernen + viel mehr testen... dann kommt es rauf...
Es ist quasi ein grober Vorschlag bis jetzt... ich wollt mal hören was ihr davon haltet.
mfg Manuel
http://paste.pocoo.org/show/195278/und hier ein kleines testprogram um zu sehen was man damit treiben kann... http://paste.pocoo.org/show/195283/
einfach als test.py abspeichern und mit ./npyck.py test.py -o pack.sh bearbeiten und schon ist das packet erstellt und ausführbar...
Nochmal: Häßlich bezieht sich auf die Namen der Funktionen und Objekte... Aber der Code sollte soweit klar sein dass man sieht dass er nix böses tut, und dann kann man ihn ja einfach mal ausprobieren...
Und das ganze kommt bald auf git, ich bin ja auch total überzeugt von git und es wird ja schon damit entwickelt... ich muss nur noch vielleicht einen besseren Namen wählen und gewisse Unschönheiten entfernen + viel mehr testen... dann kommt es rauf...
Es ist quasi ein grober Vorschlag bis jetzt... ich wollt mal hören was ihr davon haltet.
mfg Manuel
-
lunar
Nutze "except" nicht ohne konkrete Ausnahmen, und verwende die "with"-Anweisung, um Dateien zu öffnen.
npyck_class sollte NpyckClass heißen (oder gleich einen besseren Namen bekommen). Die Methode npyck_class.read ist voll mit Tabs! Zeile 42-45 kann man so zusammenfassen (Was soll der Unterstrich hinter dem g?):
Die Funktion read_pydir kann man ganz einfach so schreiben:
Warum wird die Versionsnummer nach stderr geschrieben? Ist doch keine Fehlermeldung -> stdout
Code: Alles auswählen
g_ = {'NPYCK_': 42} if use_globals else {}Code: Alles auswählen
import fnmatch
def read_pydir(dirname):
return fnmatch.filter(os.listdir(dirname), '*.py')Okay, also erstmals danke für die Beiträge...
Zuerst mal with: ich würde es ja verwenden, aber k.a. wie das mit zipfile und python 2.5 aussieht.. ich weiß da gibt es das future ding, aber da ich das zipfile garnicht schließen will seh ich nicht wirklich einen Grund das so zu lösen... wobei man sich das anders überlegen könnt.. eigentlich wollt ich ja mit zipfile.open() arbeiten und da weiß ich nicht obs okay ist während das offen ist zipfile.close() aufzurufen... (weiß nicht ob das verständlich war)
Das Problem war dass ich dauernd mit der python 2.6 docu arbeite und mich immer ärger wenn ich seh dass einiges leider wirklich erst ab python 2.6 geht... vorallem das alles lesen müssen gefällt mir überhaupt nicht.. aber python 2.5 ist nunmal nochimmer oft standartmäßig installiert und mir daher wichtig...
Dann der Klassen Name... ja naja ich weiß man sollte hier den standard modulen folgen... aber ich mag bla_bla lieber als BlaBla, ich find es geht schon zum schreiben leichter... Aber nachdem ich Standards mag, hab ich das halt abgeändert... es ist im Prinzip auch eigentlich egal, da die klasse nur Mittel zum Zweck ist, also der User sie niemals instanzieren soll, sondern einfach wenn sein Code aus dem zip heraus läuft, er gewisse dinge machen können soll (einfach)... zuerst wollt ich einfach die funktionen direkt als globale einträge übergeben, aber so ist das ganze ein bisschen sicherer (daher kam glaub ich auch das g_ und das NPYCK_ um namensübereinstimmungen zu vermeiden...)
Das mit dem if ist zwar elegant, und ich wusste nicht das man das so machen kann (ich kenns nur bei for, also eigentlich naheliegend...) aber da würd ich sagen ich leist mir die 4 zeilen code, und man sieht sofort was das ganze tut... aber ich geb dir recht dass es so eigentlich netter wäre...
read_pydir könnte man sich wohl dann auch ganz sparen, hab ich aber lassen mit dem neuen Code...
Das mit der Version hab ich auch geändert... hat mir zwar besser in stderr gefallen weil das ding ja auch als filter verwendbar ist, nachdem aber sowieso nichts getan wird wenn das --version flag gesetzt ist, ist es wahrscheinlich wirklich besser nach stdout...
Aja, hab mich auch endlich durchgerungen das ganze nach github zu stellen... [url]git://github.com/boon-code/npyck.git[/url]
Ich hoffe es passt alles und meine englischen kommentare lassen hoffentlich zumindest erahnen was ich damit sagen wollte... (wenn meine Englisch Professorin das lesen würde
) aber ich bemüh mich...
Danke nochmal an alle...
edit: http://github.com/boon-code/npyck für die github seite...
Zuerst mal with: ich würde es ja verwenden, aber k.a. wie das mit zipfile und python 2.5 aussieht.. ich weiß da gibt es das future ding, aber da ich das zipfile garnicht schließen will seh ich nicht wirklich einen Grund das so zu lösen... wobei man sich das anders überlegen könnt.. eigentlich wollt ich ja mit zipfile.open() arbeiten und da weiß ich nicht obs okay ist während das offen ist zipfile.close() aufzurufen... (weiß nicht ob das verständlich war)
Das Problem war dass ich dauernd mit der python 2.6 docu arbeite und mich immer ärger wenn ich seh dass einiges leider wirklich erst ab python 2.6 geht... vorallem das alles lesen müssen gefällt mir überhaupt nicht.. aber python 2.5 ist nunmal nochimmer oft standartmäßig installiert und mir daher wichtig...
Dann der Klassen Name... ja naja ich weiß man sollte hier den standard modulen folgen... aber ich mag bla_bla lieber als BlaBla, ich find es geht schon zum schreiben leichter... Aber nachdem ich Standards mag, hab ich das halt abgeändert... es ist im Prinzip auch eigentlich egal, da die klasse nur Mittel zum Zweck ist, also der User sie niemals instanzieren soll, sondern einfach wenn sein Code aus dem zip heraus läuft, er gewisse dinge machen können soll (einfach)... zuerst wollt ich einfach die funktionen direkt als globale einträge übergeben, aber so ist das ganze ein bisschen sicherer (daher kam glaub ich auch das g_ und das NPYCK_ um namensübereinstimmungen zu vermeiden...)
Das mit dem if ist zwar elegant, und ich wusste nicht das man das so machen kann (ich kenns nur bei for, also eigentlich naheliegend...) aber da würd ich sagen ich leist mir die 4 zeilen code, und man sieht sofort was das ganze tut... aber ich geb dir recht dass es so eigentlich netter wäre...
read_pydir könnte man sich wohl dann auch ganz sparen, hab ich aber lassen mit dem neuen Code...
Das mit der Version hab ich auch geändert... hat mir zwar besser in stderr gefallen weil das ding ja auch als filter verwendbar ist, nachdem aber sowieso nichts getan wird wenn das --version flag gesetzt ist, ist es wahrscheinlich wirklich besser nach stdout...
Aja, hab mich auch endlich durchgerungen das ganze nach github zu stellen... [url]git://github.com/boon-code/npyck.git[/url]
Ich hoffe es passt alles und meine englischen kommentare lassen hoffentlich zumindest erahnen was ich damit sagen wollte... (wenn meine Englisch Professorin das lesen würde
) aber ich bemüh mich... Danke nochmal an alle...
edit: http://github.com/boon-code/npyck für die github seite...
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Was erwartest Du von:
?
Imho stören die vielen Leerzeilen den Code. War mir nicht so, dass zwischen Methode eine und zwischen Funktionen oder Klassen jeweils zwei stehen sollen? (nach PEP8)
Die Aussage, dass Du eine Datei öffnen, aber nicht mehr schließen willst, halte ich für bedenklich. Evtl. solltest Du das mal näher erklären. Grundsätzlich gilt: Dateien immer schließen! Und das erledigt with eben auf jeden Fall.
Auch wenn 's schon erwähnt wurde:
Sehr gefährlich und vor allem unschön! Das return None ist zudem überflüssig.
In Funktionsköpfen bitte keine Leerzeichen zwischen Operatoren. Das stört auch den Lesefluss.
Code: Alles auswählen
def __del__(self):
self.close()
Imho stören die vielen Leerzeilen den Code. War mir nicht so, dass zwischen Methode eine und zwischen Funktionen oder Klassen jeweils zwei stehen sollen? (nach PEP8)
Die Aussage, dass Du eine Datei öffnen, aber nicht mehr schließen willst, halte ich für bedenklich. Evtl. solltest Du das mal näher erklären. Grundsätzlich gilt: Dateien immer schließen! Und das erledigt with eben auf jeden Fall.
Auch wenn 's schon erwähnt wurde:
Code: Alles auswählen
try:
return self._z.read(filename)
except:
return None
In Funktionsköpfen bitte keine Leerzeichen zwischen Operatoren. Das stört auch den Lesefluss.
-
lunar
@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.
Man sollte Dateien immer korrekt schließen, entweder über try...finally, oder eben über with. Bei zipfile ist für letzteres noch zusätzlich "contextlib.closing()" nötig.
Und wenn Du für 2.5 entwickeln möchtest, dann nimm doch einfach die Doku für Python 2.5.
Man sollte Dateien immer korrekt schließen, entweder über try...finally, oder eben über with. Bei zipfile ist für letzteres noch zusätzlich "contextlib.closing()" nötig.
Und wenn Du für 2.5 entwickeln möchtest, dann nimm doch einfach die Doku für Python 2.5.
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
) 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...
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
oder das:
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..
Werd versuchen mich da mehr drann zu halten, Code Standards sind (sofern sie nicht total häßlich sind wie in Java
) 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...
> 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)@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.
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
meinst du damit das:In Funktionsköpfen bitte keine Leerzeichen zwischen Operatoren
Code: Alles auswählen
def bla(arg1, arg2, arg3)Code: Alles auswählen
def bla(arg1 = True, arg2 = False, arg3 = True)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.
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.