Tach
Ich habe mir ein kleines Skript geschrieben, dass eine Bildergallerie erstellt, wo die einzelnen Seiten über PHP mit ?tid angesprochen werden können. Ich habe bisher keine gesehen, die eine solche Funktion hat, sondern bei den meisten lagen einfach unmengen von HTML Dateien in einem Ordner. Bei mir ist alles in eine "index.php" Datei reingefasst.
Noch habe ich keinen HTML Header reingebaut, da ich es erstmal für meine Bedürfnisse nicht brauche, weil ich es eh in ein Design includiere und mir deswegen nicht die mühe machen wollte. (wer das haben will kann es ja einfach am Ende und Anfang in den Code einfügen)
Es stellt sich sicherlich die Frage, warum man eine so halbstatische Gallerie will. Entweder statisch HTML oder dynamisch mit PHP. Das mag wohl richtig sein, aber leider gibt es Anbieter (vor allem FreeHoster), die keine dynamischen Bildergallerien erlauben, da diese ihnen zu viel Serverleistung beansprucht. Daher habe ich dieses Skript geschrieben. Schön kompakt eine PHP Datei und Seiten wechsel via URL
Link: http://paste.pocoo.org/show/207/
Was haltet ihr davon?
SigMA
ThumbMaker - HTML/PHP Bildergallerie
Leichtdio.de - Das Kreativ-Blog
http://www.leichtdio.de
http://www.leichtdio.de
Also bis zu 'self.pic_save' sah der Code echt gut aus PEP 8 lower_case, etc. (Einzige was nicht stimmt ist das der klassen Name mit einen kleinen Buchstaben anfängt.)
Ab ''self.pic_save' EOL über 80 Besonder Zeile 129 und 147 sind echt extrem (EOL 150?).
Die Kommentare hinter Zeile 95 und 99 würde ich auch wegmachen. Lieber über Zeile 95 und 99 schrieben. Gleiches gilt für Zeile 43-51.
lg
Ab ''self.pic_save' EOL über 80 Besonder Zeile 129 und 147 sind echt extrem (EOL 150?).
Die Kommentare hinter Zeile 95 und 99 würde ich auch wegmachen. Lieber über Zeile 95 und 99 schrieben. Gleiches gilt für Zeile 43-51.
lg
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Igitt, Inline-Kommentare! Fangen schon in Zeile 26 an und werden dann exzessiv im Rest der Datei benutzt (besonders in maker.__init__()).
Würde ich auf jeden Fall ändern.
Shebang würde ich auch ändern:
(keine Leerzeichen zwischen #! und dem Pfad zu env)
Würde ich auf jeden Fall ändern.
Shebang würde ich auch ändern:
Code: Alles auswählen
#!/usr/bin/env python
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Auch wenn ich jetzt auf Kritik stoße -> Ich würde alle Atribute, die wirklich nicht öffentlich verwendet werden sollen (oder keinen Sinn ergeben das man sie öffentlich aufruft) und halt nur intern in der klasse, mit einen unterstrich beginnen lassen. Alles mit einen unterstrich markiert das es Privat ist und das man die Sachen nicht anfasen soll.
Bevor jetzt kommt, wir sind doch alle erwachsen und so weiter: Es dient auch der Übersicht. So kann man leichter unterscheiden welche Sachen sinnvoll sind außerhalb der Klasse zu benutzen und welche nicht Das Hilft mir immer die Übersicht zu behalten (nicht nur bei meinen Klassen sondern auch bei fremden. Ein blick darauf und ich weiß was ich benutzen kann/soll und was nicht).
Aber das ist sicherlich auch Geschmacksache.
lg
Bevor jetzt kommt, wir sind doch alle erwachsen und so weiter: Es dient auch der Übersicht. So kann man leichter unterscheiden welche Sachen sinnvoll sind außerhalb der Klasse zu benutzen und welche nicht Das Hilft mir immer die Übersicht zu behalten (nicht nur bei meinen Klassen sondern auch bei fremden. Ein blick darauf und ich weiß was ich benutzen kann/soll und was nicht).
Aber das ist sicherlich auch Geschmacksache.
lg
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Aber sicherXtraNine hat geschrieben:Auch wenn ich jetzt auf Kritik stoße
Es stört beim Schreiben (zumindest tippe ich Unterstriche nur ungerne), stört beim Lesen und außerdem macht das kaum einer, und somit schreibt man Code, bei der sich die meisten Leute erstmal fragen: "Warum ist da ein Unterstrich?"XtraNine hat geschrieben:Es dient auch der Übersicht.
Aber machs wie du willst - XtraNine wird weiter Unterstriche schreiben, und der Rest wird weiter ohne auskommen
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Den Docstring vom Modul "per Hand" an `__doc__` zu binden ist ungewöhnlich. Das habe ich bisher nur zweimal so gesehen.
Die Zielordner werden in der `__init__()` erstellt, ohne das man die Chance hätte die Namen zu ändern.
Die Vergleiche eines Wahrheitswertes mit den literalen `True` und `False` sind überflüssig und werden von vielen deshalb als schlechter Stil angesehen.
Den Namen `i` in einer Schleife an etwas anderes als Integer-Objekte zu binden ist sehr verwirrend.
``s.split("/").pop()`` splitted eine Zeichenkette in viele Teile und entfernt aus der resultierenden Liste das letzte Element. Das heisst die Zeichenkette wird komplett durchlaufen und die Liste wird durch das `pop()` verändert, obwohl sie gar nicht mehr in der veränderten Form benötigt wird. Effizienter wäre ``s.rsplit('/', 1)[1]``. Das durchläuft die Zeichenkette nur bis zum ersten '/' von hinten und verändert die Ergebnisliste nicht unnötig.
``(size[0], size[1])`` ist eine umständliche Art ``size`` zu schreiben. Und ist der Test ob einer der Werte 0 ist, wirklich nötig?
Die PHP/Python-Mischung ist sehr unübersichtlich, und `i` jetzt in einer ``while i:``-Schleife als Abbruchbedingung zu nutzen... Argh!
Und der Docstring bei `make_me_all()` drückt sehr schön aus, das es sich eigentlich um Funktionen handelt. Das das alles in einer Klasse steht, hat eigentlich keinen tieferen Sinn, das hätte man auch prima mit ein paar Funktionen lösen können.
Die Zielordner werden in der `__init__()` erstellt, ohne das man die Chance hätte die Namen zu ändern.
Die Vergleiche eines Wahrheitswertes mit den literalen `True` und `False` sind überflüssig und werden von vielen deshalb als schlechter Stil angesehen.
Den Namen `i` in einer Schleife an etwas anderes als Integer-Objekte zu binden ist sehr verwirrend.
``s.split("/").pop()`` splitted eine Zeichenkette in viele Teile und entfernt aus der resultierenden Liste das letzte Element. Das heisst die Zeichenkette wird komplett durchlaufen und die Liste wird durch das `pop()` verändert, obwohl sie gar nicht mehr in der veränderten Form benötigt wird. Effizienter wäre ``s.rsplit('/', 1)[1]``. Das durchläuft die Zeichenkette nur bis zum ersten '/' von hinten und verändert die Ergebnisliste nicht unnötig.
``(size[0], size[1])`` ist eine umständliche Art ``size`` zu schreiben. Und ist der Test ob einer der Werte 0 ist, wirklich nötig?
Die PHP/Python-Mischung ist sehr unübersichtlich, und `i` jetzt in einer ``while i:``-Schleife als Abbruchbedingung zu nutzen... Argh!
Und der Docstring bei `make_me_all()` drückt sehr schön aus, das es sich eigentlich um Funktionen handelt. Das das alles in einer Klasse steht, hat eigentlich keinen tieferen Sinn, das hätte man auch prima mit ein paar Funktionen lösen können.
Ach was, jetzt übertreibst du ca. 90% der Module machen das auch in ihren Klassen. Sogar in den Standardmodulen die von Python mitgeliefert werden. Ich glaube bei Pocoo habe ich auch schon Unterstriche gesehen ^^Leonidas hat geschrieben:[...]
Aber machs wie du willst - XtraNine wird weiter Unterstriche schreiben, und der Rest wird weiter ohne auskommen
ähm ... der erste Teil ist doch config Teil. Da kann man auch den Pfad ändern. Ich wollte nur nicht, alles __init__() zuübergeben,BlackJack hat geschrieben:Die Zielordner werden in der `__init__()` erstellt, ohne das man die Chance hätte die Namen zu ändern.
Bei mir ist 'i' eine Standart Schleifen Variabel. Zeugt vllt. von schlechtem Stil, aber das ist quasi ein ReflexBlackJack hat geschrieben: Den Namen `i` in einer Schleife an etwas anderes als Integer-Objekte zu binden ist sehr verwirrend.
ja .. öhm *hust* Das war absicht ;D Und ja die Abfrage nach dem Wert != 0 ist wichtig, da wenn Wert == 0 ist er das Bild nicht verkleinern/vergrößern soll.BlackJack hat geschrieben:``(size[0], size[1])`` ist eine umständliche Art ``size`` zu schreiben. Und ist der Test ob einer der Werte 0 ist, wirklich nötig?
Wie gesagt die PHP/Python Mischung, weil es eine PHP Datei wird und Python die erstellt. FreeHoster unterstützen Python eben nicht^^BlackJack hat geschrieben:Die PHP/Python-Mischung ist sehr unübersichtlich, und `i` jetzt in einer ``while i:``-Schleife als Abbruchbedingung zu nutzen... Argh!
SigMA
Leichtdio.de - Das Kreativ-Blog
http://www.leichtdio.de
http://www.leichtdio.de
Das war kein Argument gegen PHP, sondern dass diese Funktion so wie sie da steht, furchtbar unübersichtlich ist. Das kann man besser trennen. Die PHP-Zeichenketten könnte man zum Beispiel mit Platzhaltern versehen, am Anfang der Funktion an Namen binden und dann mit `string.Template()` die Werte eintragen. Ein Mini-Template sozusagen.SigMA hat geschrieben:Wie gesagt die PHP/Python Mischung, weil es eine PHP Datei wird und Python die erstellt. FreeHoster unterstützen Python eben nichtBlackJack hat geschrieben:Die PHP/Python-Mischung ist sehr unübersichtlich, und `i` jetzt in einer ``while i:``-Schleife als Abbruchbedingung zu nutzen... Argh!
-
- User
- Beiträge: 312
- Registriert: Dienstag 24. Oktober 2006, 19:31
Hallo,
Python zu verwenden um PHP Spaghetticode zu erzeugen
0 Punkte.
W A R E I N S C H E R Z
Muss man in diesem Forum doch immer besser dazuschreiben
Im Ernst:
Nimm dir Blackjacks Tipps zu Herzen.
Da Python eine Sprache ist, die explizit effiziente prozuderale-, funktionale- usw. sowie oop ermöglicht, sollte man nur dann Klassen definieren, wenn sie tatsächlich einen Mehrwert darstellen.
OOP in Python - no other way to do it ? - then do it.
Grundsätzlich würde ich im Konstruktor keine fixen Werte definieren, wenn möglich. Lieber Defaultwerte, die beim Aufruf aber auch geändert werden können.
Wenn das nicht zur Diskussion steht, würde ich mir überlegen diese als Klassenvariablen zu definieren.
Also:
Das mit dem Namen i habe ich mir auch abgewöhnt. Es ist auch für einen selber viel angenehmer, wenn man den Code leist.
@Leonidas
Das mit den Inlinekommentaren ist eine Frage wie man es lieber mag.
Es ist auch aus mediendidaktischer Sicht durchaus sinnvoll diese zu machen, weil es für einen Lesenden, Lernenden das Verständnis erleichtern kann - natürlich nicht muss.
Liebe Grüße
rolgal_reloaded
Python zu verwenden um PHP Spaghetticode zu erzeugen
0 Punkte.
W A R E I N S C H E R Z
Muss man in diesem Forum doch immer besser dazuschreiben
Im Ernst:
Nimm dir Blackjacks Tipps zu Herzen.
Da Python eine Sprache ist, die explizit effiziente prozuderale-, funktionale- usw. sowie oop ermöglicht, sollte man nur dann Klassen definieren, wenn sie tatsächlich einen Mehrwert darstellen.
OOP in Python - no other way to do it ? - then do it.
Grundsätzlich würde ich im Konstruktor keine fixen Werte definieren, wenn möglich. Lieber Defaultwerte, die beim Aufruf aber auch geändert werden können.
Wenn das nicht zur Diskussion steht, würde ich mir überlegen diese als Klassenvariablen zu definieren.
Also:
Code: Alles auswählen
class maker:
width = 5 # Anzahl der Bilder in der Breite
height = 5 # Anzahl der Bilder in der Höhe
thumb_size = (150, 150) # Die Breite der VorschauBilder
pic_size = (800, 600)
def __init__(self):
""" irgendwas anderes passiert hier"""
Das mit dem Namen i habe ich mir auch abgewöhnt. Es ist auch für einen selber viel angenehmer, wenn man den Code leist.
@Leonidas
Das mit den Inlinekommentaren ist eine Frage wie man es lieber mag.
Es ist auch aus mediendidaktischer Sicht durchaus sinnvoll diese zu machen, weil es für einen Lesenden, Lernenden das Verständnis erleichtern kann - natürlich nicht muss.
Liebe Grüße
rolgal_reloaded
Das ist ne gute Idee. Ich bau das morgen mal einDas war kein Argument gegen PHP, sondern dass diese Funktion so wie sie da steht, furchtbar unübersichtlich ist. Das kann man besser trennen. Die PHP-Zeichenketten könnte man zum Beispiel mit Platzhaltern versehen, am Anfang der Funktion an Namen binden und dann mit `string.Template()` die Werte eintragen. Ein Mini-Template sozusagen.
SigMA
Leichtdio.de - Das Kreativ-Blog
http://www.leichtdio.de
http://www.leichtdio.de
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
rolgal_reloaded hat geschrieben:Das mit den Inlinekommentaren ist eine Frage wie man es lieber mag.
Es ist auch aus mediendidaktischer Sicht durchaus sinnvoll diese zu machen, weil es für einen Lesenden, Lernenden das Verständnis erleichtern kann - natürlich nicht muss.
Aber PEP8 mal ganz nebenbei. Inline Comments finde ich aus mehreren Gründen schlecht:PEP8 hat geschrieben:Use inline comments sparingly.
- mischen von Code und Kommentar in einer Zeile finde ich unübersichtlich
- kann sehr lang werden und daher die Zeilenlänge unnötig verlängern
- man weiß nicht wo er anfangen muss (d.h. wie weit das # reingerückt sein muss) damit es konsistent ist. Bei kommentaren die über dem Code stellen ist es ja ersichtlich: genauso weit eingerückt wie der Code den sie beschrieben. Ich mag konsistenz.
- Kommentare, zumindest bei mir, auch mehrzeilig werden können und daher als Inline-Kommentare entweder sehr lang werden würden, oder umgebrochen werden müssten und dazu dann noch aufwendig formatiert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 312
- Registriert: Dienstag 24. Oktober 2006, 19:31
@Leonidas
ich mag nicht wenn PEP8 zu einer Art Bibel wird.
Ich wollte eigentlich was anderes sagen. Es ist Fakt, dass jeder Präferenzen bez. des Layouts von Informationen hat.
Person A: bevorzugt Bild links, Text rechts.
Person B: bevorzugt genau das Gegenteil.
Das Beispiel ist plakativ, aber so verhaltet es sich mit vielen Dingen.
LG
rolgal_reloaded
ich mag nicht wenn PEP8 zu einer Art Bibel wird.
Ich wollte eigentlich was anderes sagen. Es ist Fakt, dass jeder Präferenzen bez. des Layouts von Informationen hat.
Person A: bevorzugt Bild links, Text rechts.
Person B: bevorzugt genau das Gegenteil.
Das Beispiel ist plakativ, aber so verhaltet es sich mit vielen Dingen.
LG
rolgal_reloaded
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ich habe es hier nur der Vollständigkeit halber erwähnt und dann noch vier eigene Gründe hinzugefügt, warum ich Inlinekommentare nicht mag. Mehr als die offizielle Position und meine eigene zu erklären kann ich nicht. Allerdings finde ich, dass meine Gründe durchaus gut sind und auch nachvollziehbar, da ist keine Dogmatik dabei, das sind einfach meine eigenen Alltagserfahrungen die ich nach mehreren Jahren programmieren mit Python hir einbringe.rolgal_reloaded hat geschrieben:ich mag nicht wenn PEP8 zu einer Art Bibel wird.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 312
- Registriert: Dienstag 24. Oktober 2006, 19:31
Habe ich auch nicht verlangt, oder? Deine vier Gründe haben ja eh bestätigt was ich gemeint habe.Leonidas hat geschrieben: Ich habe es hier nur der vollständigkeit halber erwähnt und dann noch vier eigene Gründe hinzugefügt, warum ich Inlinekommentare nicht mag. Mehr als die offizielle Position und meine eigene zu erklären kann ich nicht.
Liebe Grüße
rolgal_reloaded
@rolgal: Letztendlich entscheidend der eigene Geschmack, es sei den man Arbeitet mit mehreren an einem Projekt. Da hat die persönliche Note nichts zu suchen. Dort muss man sich einigen damit man einen einheitlichen Code schriebt und nicht einen Code gemischt aus verschiedenen persönlichen Styles. MMn ist da PEP 8 ne gut Richtlinie.
Ich denke Leonidas wollte aber nur mal generell darauf hinweisen, dass es nicht PEP 8 Konform ist. Ich persönlich finde es nicht schlecht. Hätte mich damals einige nicht darauf hingewiesen, würde ich immer noch mixedCase und sonstigen "Unsinn" verwenden, wie 'MyClassException' statt 'MyClassError' oder '(x+1) *' (y-1) statt '(x + 1) * (y - 1)' oder 'type()' statt 'isinstance()' und vieles mehr.
Aber gut, das mit inline Comments ist nun nicht so schlimm wie andere Sachen die im PEP 8 stehen.
Es gibt aber für mich immer noch einige Sachen die mich auch an PEP 8 selber stören.
z.B. Bei reservierten Worten: statt 'lst' soll man dann lieber im Zweifelsfall 'list_' schreiben (das ist der einzige Fall wo ich keine Unterstriche mag. Wenn Unterstriche dann am Anfang und nur um es als private zu kennzeichnen *gg)
Ich denke Leonidas wollte aber nur mal generell darauf hinweisen, dass es nicht PEP 8 Konform ist. Ich persönlich finde es nicht schlecht. Hätte mich damals einige nicht darauf hingewiesen, würde ich immer noch mixedCase und sonstigen "Unsinn" verwenden, wie 'MyClassException' statt 'MyClassError' oder '(x+1) *' (y-1) statt '(x + 1) * (y - 1)' oder 'type()' statt 'isinstance()' und vieles mehr.
Aber gut, das mit inline Comments ist nun nicht so schlimm wie andere Sachen die im PEP 8 stehen.
Es gibt aber für mich immer noch einige Sachen die mich auch an PEP 8 selber stören.
z.B. Bei reservierten Worten: statt 'lst' soll man dann lieber im Zweifelsfall 'list_' schreiben (das ist der einzige Fall wo ich keine Unterstriche mag. Wenn Unterstriche dann am Anfang und nur um es als private zu kennzeichnen *gg)