Diskussion zu PEP8!

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Hallo :)

Ich würde mal mit euch gerne über PEP8 Diskutieren. -> http://www.python.org/dev/peps/pep-0008/

Also erstmal: Es sind sehr viele sinnvolle Sachen drin, aber auch _weniger_ sinnvoll und beschränkende!

YES:
hypot2 = x * x + y * y
c = (a + b) * (a - b)

NO:
hypot2 = x*x + y*y
c = (a+b) * (a-b)


:stupid: aber so was von! x * x + y * y ist total unleserlich, wogegen x*x + y*y leserlich ist, da die Terme so zusammengerückt sind was die Leserlichkeit erhöht. OK, in diesem Fall recht trivial aber bei komplexeren beispielen...

Dann das ->(a + b) * (a - b) -> genau das gleiche.
So bekommt man es in der schule beigebracht -> (a+b) * (a-b) aber man soll es unleserlich machen like (a + b) * (a - b)... :roll:

OK genug aufgeregt :P

Code: Alles auswählen

Function Names

      Function names should be lowercase, with words separated by underscores
      as necessary to improve readability.

      mixedCase is allowed only in contexts where that's already the
      prevailing style (e.g. threading.py), to retain backwards compatibility.
Toll! Was soll das den bitte? Warum darf ich nicht meine Methode/Funktion MyFunction nenne und werde dazu gezwungen es my_function zu nenne, was für mich total unästhetisch aussieht?

Ich hab es mir angewöhnt, das alle Methoden mit einen Großen Buchstaben anfangen und alle beinhalteten Worte ebenfalls mit einen Großen anfangen. Desweiteren fangen bei mir alle öffentlichen Attribute von einer Klasse mit einen kleinen Buchstaben an und alle weiteren Worte fangen mit einen Großen an. --> MyMethod(), myAttribut

Was haltet ihr davon und welche Sachen von PEP8 gehen euch auf den Sack!?

lg
CM
User
Beiträge: 2464
Registriert: Sonntag 29. August 2004, 19:47
Kontaktdaten:

Ich finde Du solltest Dich erst einmal beruhigen. Auch einige Pythonprojekte verstoßen gegen diese Richtlinie. Sie hat schon ihre guten Seiten, aber man will ja auch niemanden dazu zwingen sie zu befolgen. Was Leserlichkeit anbelangt: Lingua Franca der Programmierung ist nun mal Englisch und in anderen Sprachräumen wird nun mal nicht nur anders gesprochen, sondern auch Text und Formeln anders formatiert. Man gewöhnt sich dran. Und wenn es Dir nicht gefällt, dann mach' es halt anders - wie ich auch sehr oft ...

Gruß,
Christian
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Ja hast recht, ich sollte mich echt nicht aufregen und wider beruhigen. Ich hatte bloß gerade PEP8 ein wenig versucht zu lesen und da habe ich die Zeilen entdeckt und musste daran denken: "Oh Gott, meine ganzen angefangenen Python Scripte sind für die Katz, weil sie gegen PEP8 verstoßen sind :("

lg
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Ich find pep8 gut. Halte mich dran, nur EOL 80 ist etwas schwer einzuhalten bei verschachteltem Code. In pocoo haben wir EOL 90. lower_case_with_underscores find ich auch gut. :-)
Rundum zufrieden mit PEP8
TUFKAB – the user formerly known as blackbird
N317V
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

Sich das sklavisch daran zu halten, ist ja auch nicht Sinn des Ganzen. Mir fallen da auch diverse Dinge auf, z.B.
PEP8 hat geschrieben:Code should be written in a way that does not disadvantage other
implementations of Python (PyPy, Jython, IronPython, Pyrex, Psyco,
and such).
Das ist mir sowas von wurscht. Da kann und will ich nicht immer darauf achten. Das liegt IMHO in der Verantwortung derjenigen, die besagte Implementationen zur Verfügung stellen.
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
BlackJack

XtraNine hat geschrieben:Also erstmal: Es sind sehr viele sinnvolle Sachen drin, aber auch _weniger_ sinnvoll und beschränkende!

YES:
hypot2 = x * x + y * y
c = (a + b) * (a - b)

NO:
hypot2 = x*x + y*y
c = (a+b) * (a-b)


:stupid: aber so was von! x * x + y * y ist total unleserlich, wogegen x*x + y*y leserlich ist, da die Terme so zusammengerückt sind was die Leserlichkeit erhöht. OK, in diesem Fall recht trivial aber bei komplexeren beispielen...

Dann das ->(a + b) * (a - b) -> genau das gleiche.
So bekommt man es in der schule beigebracht -> (a+b) * (a-b) aber man soll es unleserlich machen like (a + b) * (a - b)... :roll:
Die Beispiele sind, wie Du ja selbst schon bemerkt hast, so trivial dass es nicht wirklich einen Unterschied macht. Wenn Du die Bindungsstärke bei ``x * x + y * y`` optisch besser hervorheben möchtest, dann kannst Du Klammern setzen: ``(x * x) + (y * y)``.

Ich finde es aus zwei Gründen sinnvoll die Leerzeichen immer zu machen. Zum einen sieht die Sache mit der Leserlichkeit schon anders aus, wenn längere Namen im Spiel sind

foo_bar*frob*nitz -> foo_bar * frob * nitz

Das erste kann unter Umständen wie ein langes "Wort" wirken, das zweite besteht optisch eindeutig aus drei Teilen.

Und der zweite Grund ist aus dem Python-Zen: Special cases aren't special enough to break the rules.

Anstatt sich jedesmal wenn man einen Operator benutzt, Gedanken zu machen ob man nun Leerzeichen setzt oder nicht, ist es einfacher immer welche zu machen. Insbesondere wenn der Quelltext von mehreren Leuten bearbeitet wird, dann haben die vielleicht unterschiedliche ästhetische Vorstellungen und das Programm fängt an uneinheitlich zu werden.

Code: Alles auswählen

Function Names

      Function names should be lowercase, with words separated by underscores
      as necessary to improve readability.

      mixedCase is allowed only in contexts where that's already the
      prevailing style (e.g. threading.py), to retain backwards compatibility.
Toll! Was soll das den bitte? Warum darf ich nicht meine Methode/Funktion MyFunction nenne und werde dazu gezwungen es my_function zu nenne, was für mich total unästhetisch aussieht?
Das soll dazu führen, dass man den Quelltext von anderen Leuten einfacher verstehen kann. Wenn ich einen Namen sehe, der mit einem Grossbuchstaben beginnt, dann denke ich: Ah, eine Klasse! Und das geht höchstwahrscheinlich 99% der Python-Programmierer so.

Und wenn man im Hinterkopf hat, dass es im `viking` Modul eine Funktion gibt, um den Drachen aufzuwecken, dann braucht man nicht überlegen ob die nun `WakeDragon()`, `wakeDragon()` oder `wake_dragon()` heisst.
BlackJack

N317V hat geschrieben:Sich das sklavisch daran zu halten, ist ja auch nicht Sinn des Ganzen. Mir fallen da auch diverse Dinge auf, z.B.
PEP8 hat geschrieben:Code should be written in a way that does not disadvantage other
implementations of Python (PyPy, Jython, IronPython, Pyrex, Psyco,
and such).
Das ist mir sowas von wurscht. Da kann und will ich nicht immer darauf achten. Das liegt IMHO in der Verantwortung derjenigen, die besagte Implementationen zur Verfügung stellen.
Ähm, vielleicht sollte man nochmal darauf hinweisen für wen diese Regeln "gelten": Dieses PEP ist "bindend" für Quelltext der in die Standardbibliothek aufgenommen werden soll. Und da finde ich es schon sinnvoll wenn die darauf achten, dass das keine CPython-only Veranstaltung wird, wenn man es auch unter den Implementierungen portabler gestalten kann.

Wenn es nur für CPython wäre, könnte man sehr oft ein explizites schliessen von Dateien einsparen und den Quelltext damit evt. für andere Python-Implementierungen unbrauchbar machen.
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

@BlackJack:
OK, danke für dein feedback. Von der Seite habe ich das nich nciht gesehen. Dann werde ich mir das auch angewöhnen und dann meine Methoden alle lowercase machen (naja, hätte ich das vorher gewusst, müsste ich nu nicht alle meine sourcefiles ändern :-[)

Aber noch ne Seeziele frage Jack: Wie sieht es mit wxPython aus? Sollte ich mich in diesem speziellen Fall anpassen, wenn ich ne klasse schreibe die z.B. von wx.Panel gerbt ist? Oder sollte ich da PEP8 auch stur befolgen und alle Methoden lowercase machen? bzw. oder sollte ich bei einem wxPython Programm konsequent sowohl Programmlogik wie auch GUI teil nach PEP8 schreiben?

lg
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

XtraNine hat geschrieben:Also erstmal: Es sind sehr viele sinnvolle Sachen drin, aber auch _weniger_ sinnvoll und beschränkende!
Ich sehe in deinen Beispielen keine Beschränkungen die dir PEP8 auferlegt.
XtraNine hat geschrieben::stupid: aber so was von! x * x + y * y ist total unleserlich, wogegen x*x + y*y leserlich ist, da die Terme so zusammengerückt sind was die Leserlichkeit erhöht. OK, in diesem Fall recht trivial aber bei komplexeren beispielen...
Ich persönlich finds leserlicher wenns nicht so zusammengequtscht ist. Wobei mir das recht egal ist, aber bei Zuweisungen wie wert=4 (also ohne Leerzeichen) stehen mir die Haare zu Berge. Inline-Comments finde ich auch schlimm, weil sie einfach stören (Copy & Paste und so) und es keinen Grund gibt, warum sie nicht über dem Code stehen können, den sie beschreiben.
XtraNine hat geschrieben:So bekommt man es in der schule beigebracht -> (a+b) * (a-b) aber man soll es unleserlich machen like (a + b) * (a - b)... :roll:
((a+b)*(a-b))/((b-a)/(a**b)) soll leserlicher sein als ((a+b) * (a-b)) / ((b - a) / (a**b))? Naja, gut, unleserlich sind beide, wenn man Formeln in einer Zeile schriebt wird sowas generell hässlich.
XtraNine hat geschrieben:Toll! Was soll das den bitte? Warum darf ich nicht meine Methode/Funktion MyFunction nenne und werde dazu gezwungen es my_function zu nenne, was für mich total unästhetisch aussieht?
Ney. Du wirst gebeten das so zu machen, wie die meisten Python-Programmierer es auch tun, weil sie es leserlicher finden. Mich eingeschlossen.
XtraNine hat geschrieben:Ich hab es mir angewöhnt, das alle Methoden mit einen Großen Buchstaben anfangen und alle beinhalteten Worte ebenfalls mit einen Großen anfangen. Desweiteren fangen bei mir alle öffentlichen Attribute von einer Klasse mit einen kleinen Buchstaben an und alle weiteren Worte fangen mit einen Großen an. --> MyMethod(), myAttribut
"Ich habe mir angewohnt private und public zu verwenden, ich habe mir angewöhnt Getter und Setter für jeden Quark zu schrieben, ich habe mir angewöhnt pro Klasse eine Datei zu schreiben, ich habe mir angewöhnt meine main() Funktion in eine Klasse zu packen, ich habe mir angewöhnt, Klassen überall zu verwenden, auch dort wo sie stören. Könnte aber auch sein, dass Java mir vieles angewöhnt hat, weil es mir keine Wahl ließ."
Python lässt dir die Wahl und bei vielen Dingen lohnt es sich, seine Gewohnheiten zu ändern.
XtraNine hat geschrieben:Was haltet ihr davon und welche Sachen von PEP8 gehen euch auf den Sack!?
Mich nervt das 1-Zeile pro Import. Ich gruppiere meine Imports meist in der Reihenfolge: Stdlib, externe Abhängigkeiten, Module meines Programmes. Und daran wird auch PEP8 nichts ändern, denn das macht meiner Meinung nach Sinn, nicht nur ästhetischen, sondern dient der Übersichtlichkeit, welches Modul woher kommt. Aber statt die Imports einzuklammern und über mehrere Zeilen zu verteilen schreibe ich mehrere Imports dann doch auf mehrere Zeilen.
XtraNine hat geschrieben:"Oh Gott, meine ganzen angefangenen Python Scripte sind für die Katz, weil sie gegen PEP8 verstoßen sind :("
Stimmt, war bei mir auch so. Meine ganzen Anfänger-Skripte wurden durch PEP8 entwertet, und zwar zu recht, wenn ich mir ansehe, was ich da für Quark gemacht habe. Allerdings habe ich viele Sachen aus dem PEP8 schon vor dem Lesen befolgt.
N317V hat geschrieben:Sich das sklavisch daran zu halten, ist ja auch nicht Sinn des Ganzen.
Das tue ich auch nicht. Ich befolge die Meisten sachen, die mir sinnvoll erscheinen (also die große Mehrheit) und gehe dort eigene Wege wo ich es für sinnvoll halte.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

XtraNine hat geschrieben:Aber noch ne Seeziele frage Jack: Wie sieht es mit wxPython aus? Sollte ich mich in diesem speziellen Fall anpassen, wenn ich ne klasse schreibe die z.B. von wx.Panel gerbt ist? Oder sollte ich da PEP8 auch stur befolgen und alle Methoden lowercase machen? bzw. oder sollte ich bei einem wxPython Programm konsequent sowohl Programmlogik wie auch GUI teil nach PEP8 schreiben?
Also wxPython umzubeigen würde ich nicht machen (obwohl es definitiv halbwegs sauber sogar möglich ist, siehe meinen alten, nie benutzten Hack namens qtwrap, welches Qt-Objekte umbenennt). Jedoch würde ich den Rest des Programmes schon PEP8-konform schreiben, denn man muss ja nicht wxPython in allem Nacheifern. Stell dir vor, du nutzt zwei Libs mit verschiedenen Case-Spielarten, welche würdest du dann für dein Programm nutzen?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
N317V
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

Leonidas hat geschrieben:Allerdings habe ich viele Sachen aus dem PEP8 schon vor dem Lesen befolgt.
Yo, wenn man in einem Team zusammen arbeitet, muss man sich ohnehin auf manche Konventionen einigen. Lustigerweise ist mir beim erstmaligen Lesen von PEP8 aufgefallen, dass das meiste mit dem Stil übereinstimmt, auf den ich mich mit Kollegen bereits geeinigt hatte, als ich Python noch gar nicht kannte.
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
BlackJack

XtraNine hat geschrieben:Aber noch ne Seeziele frage Jack: Wie sieht es mit wxPython aus? Sollte ich mich in diesem speziellen Fall anpassen, wenn ich ne klasse schreibe die z.B. von wx.Panel gerbt ist? Oder sollte ich da PEP8 auch stur befolgen und alle Methoden lowercase machen? bzw. oder sollte ich bei einem wxPython Programm konsequent sowohl Programmlogik wie auch GUI teil nach PEP8 schreiben?
Einer der Hauptgründe ist ja die Regelmässigkeit, damit andere nicht verwirrt werden, also würde ich bei eigenen `wx` Klassen die Regeln von `wx` benutzen. Bei der Programmlogik würde ich mich eher an PEP8 halten, insbesondere weil ich versuchen würde die Logik und die GUI möglichst getrennt zu halten. Wenn dabei dann Module entstehen, die man auch in ganz anderen Kontexten wiederverwenden kann, dann hat man da plötzlich mixedCase-Namen aber kein `wx` mehr.

@Leonidas: Ein import pro Zeile und diese nach einem bestimmten Muster geordnet, hat sich bei mir in der Vergangenheit bewährt wenn mehrere Programmierer und eine Versionsverwaltung im Spiel sind. Das gibt wesentlich weniger Konflikte und Mehrfachimporte wenn man eindeutig festlegt wo ein import hinkommt.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:@Leonidas: Ein import pro Zeile und diese nach einem bestimmten Muster geordnet, hat sich bei mir in der Vergangenheit bewährt wenn mehrere Programmierer und eine Versionsverwaltung im Spiel sind. Das gibt wesentlich weniger Konflikte und Mehrfachimporte wenn man eindeutig festlegt wo ein import hinkommt.
Hmm, es ist ja sicher so, dass das auch Vorteile hat, aber wenn ich Module sehe wo dann erstmal eine Bildschirmseite Importe sind, kommt mir das einfach nur seltsam vor (besonders da ja erst vor gar nicht so langer Zeit die Import-Statements auch noch erweitert wurden, dass man einen Import über mehrere Zeilen leiten kann).
Wobei ich das Problem nie habe, dass mehrere Autoren an einer Datei gleichzeitig editieren, stimmt natürlich auch wieder.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Leonidas hat geschrieben:
XtraNine hat geschrieben:So bekommt man es in der schule beigebracht -> (a+b) * (a-b) aber man soll es unleserlich machen like (a + b) * (a - b)... :roll:
((a+b)*(a-b))/((b-a)/(a**b)) soll leserlicher sein als ((a+b) * (a-b)) / ((b - a) / (a**b))? Naja, gut, unleserlich sind beide, wenn man Formeln in einer Zeile schriebt wird sowas generell hässlich.
Ne da hast du mich falsch verstanden. Zwischen zwei Termen kommt auch ein leerzeichen bei mir. -> Also ich würde das auch so schreiben: ((a+b) * (a-b)) / ((b - a) / (a**b)) … Aber so würde ich das nicht schreiben weil es für mcih unleserlich ist.: ( (a + b ) * ( a – b ) ) / ( ( b – a ) / ( a ** b) ). Aber nach PEP8 wäre letzteres richtig. Aber ich denke das ich das nicht mit übernehmen werde.
Leonidas hat geschrieben:
XtraNine hat geschrieben:Toll! Was soll das den bitte? Warum darf ich nicht meine Methode/Funktion MyFunction nenne und werde dazu gezwungen es my_function zu nenne, was für mich total unästhetisch aussieht?
Ney. Du wirst gebeten das so zu machen, wie die meisten Python-Programmierer es auch tun, weil sie es leserlicher finden. Mich eingeschlossen.
Ok, dann werde ich das wohl auch machen müssen
Leonidas hat geschrieben: Also wxPython umzubeigen würde ich nicht machen (obwohl es definitiv halbwegs sauber sogar möglich ist, siehe meinen alten, nie benutzten Hack namens qtwrap, welches Qt-Objekte umbenennt). Jedoch würde ich den Rest des Programmes schon PEP8-konform schreiben, denn man muss ja nicht wxPython in allem Nacheifern. Stell dir vor, du nutzt zwei Libs mit verschiedenen Case-Spielarten, welche würdest du dann für dein Programm nutzen?
Ok, dan mache ich Logikteil nach PEP8 und den GUI teil nach wx. Aber deine frage verstehe ich nicht ganz bzw. weiß nicht genau was du meinst. Falls ich
das richtig versteh, dann folgende antwort: Also ich würde es nicht davon abhängig machen ob es lower_case oder UpperCase ist, sondern wie leistungsfähig und gut die Lib ist. Ich finde wxPython nicht schlecht und würde und werde nicht deswegen wechseln nur weil es gegen PEP8 verstößt. GTK persönlich gefällt mir gar nicht, was letztendlich auch daran liegt das die GUIs einfach für mich schlecht aussehen auf Windows. wxPython passt sich da dem Stil von Windows bzw. des jeweiligen OS an und genau das finde ich richtig gut :)

Noch ne Frage: Welche PEPs sind die wichtigsten die man unbedingt vorher gelesen und könen sollte? Ich würde mich dann daran machen das alles zu lesen und ins Deutsche mit Dictionary und Google (Bin nicht so gut in Englisch aber das geht schon ^^) zu übersetzen und würde das dann auch hier posten :)

lg
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

XtraNine hat geschrieben:Aber deine frage verstehe ich nicht ganz bzw. weiß nicht genau was du meinst.
Stell dir vor, du nutzt zwei Libs, eine benutzt CamelCase und die andere mixedCase. Wenn du PEP8 ignorieren würdest hättest du an dieser Stelle ein Problem: welches Case nun übernehmen. Eben aus dem Grund würde ich PEP8-Case universell nutzen.
Wenn ich aber wxPython Klassen ableite (wx.Panel zum Beispiel), dann würde ich mich doch an die wx-Case halten.
XtraNine hat geschrieben:Falls ich das richtig versteh, dann folgende antwort: Also ich würde es nicht davon abhängig machen ob es lower_case oder UpperCase ist, sondern wie leistungsfähig und gut die Lib ist.
Nein, das war nicht gemeint. Wer sucht sich schon die Libs dach ihren Coding Guidelines aus? ;)
XtraNine hat geschrieben:Ich finde wxPython nicht schlecht und würde und werde nicht deswegen wechseln nur weil es gegen PEP8 verstößt. GTK persönlich gefällt mir gar nicht, was letztendlich auch daran liegt das die GUIs einfach für mich schlecht aussehen auf Windows.
Ich bin einer der wxPython-API-Flüchtlinge ;) Liegt aber nicht am CamelCase, sondern an der C++ness von dessen API, und (damals) an den Tonnen von Bugs.
XtraNine hat geschrieben:wxPython passt sich da dem Stil von Windows bzw. des jeweiligen OS an und genau das finde ich richtig gut :)
Tut GTK auch, darüber habe ich mal auf d.c.l.p diskutiert. Guck mal hier, da ist auch ein Screenshot unter Windows XP, mit XP-Stil.
XtraNine hat geschrieben:Noch ne Frage: Welche PEPs sind die wichtigsten die man unbedingt vorher gelesen und könen sollte?
"Unbedingt" seind keine zu lesen, zu den wichtigeren zählen aber PEP 20, 249, 257, 290, etc, etc. Sorry dass ich hier keine Umfassende Liste poste, aber um ehrlich zu sein, habe ich nur die PEPs gelesen, die ich selbst benötigt habe und nicht auf Vorrat PEPs auswendig gelernt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Thx :)

OK, GTK habe ich mit tkinter verwechselt ^^ Ich schaue mir mal GTK genauer an. Die Screenshots haben mich überzeugt. Oh man schon wider über 1000 Zeilen Code in den Virtuellen Mülleimer schmeißen ^^

GTK ist aber Pythonischer oder? Bitte sag Ja ^^
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

XtraNine hat geschrieben:OK, GTK habe ich mit tkinter verwechselt ^^ Ich schaue mir mal GTK genauer an. Die Screenshots haben mich überzeugt. Oh man schon wider über 1000 Zeilen Code in den Virtuellen Mülleimer schmeißen ^^
Wenn dir wxPython taugt, bleib dabei. Ich habe nicht gesagt dass wxPython schlecht ist. Es war mal schlecht, wie es im Moment ist, kann ich dir nicht sagen, da ich es nicht mehr nutze. Kann schon sein, dass es inzwischen besser geworden ist, es gibt hier mehrere Leute im Forum die es gerne nutzen.
XtraNine hat geschrieben:GTK ist aber Pythonischer oder? Bitte sag Ja ^^
Naja, die PyGTK-Bindungen kommen mir persönlich angenehmer zum programmieren vor. Kann aber auch daran liegen, dass sie besser Dokumentiert sind. Und hmm.. einige Sachen wie TreeViews sind auch in PyGTK unnötig komplex.
Wie gesagt, schau dir beide an und entscheide selbst. Ich kann dich nur auf die Vorteile der einzelnen Toolkits verweisen, entscheiden musst du aber selbst.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sape
User
Beiträge: 1157
Registriert: Sonntag 3. September 2006, 12:52

Danke. Ich werde mir GTK anschauen :)

lg
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

BlackJack hat geschrieben:also würde ich bei eigenen `wx` Klassen die Regeln von `wx` benutzen. Bei der Programmlogik würde ich mich eher an PEP8 halten, insbesondere weil ich versuchen würde die Logik und die GUI möglichst getrennt zu halten.
Hi BlackJack!

Ich schreibe meine Klassenmethoden klein, auch wenn im wxPython die Methoden "GroßKlein" geschrieben sind.

Das hat mehrere Gründe:

1.) Ich muss nicht ständig nachdenken welche der Buchstaben jetzt groß und welche klein geschrieben werden müssen.

2.) Ich überschreibe **nicht** versehentlich eine wxPython-Methode -- was mir schon mal passiert ist. :roll:

3.) Solche Eventhandler-Namen wie sie im wxPython-Styleguide vorgeschlagen werden, z.B. ``OnButton``, machen sowiso keinen Sinn, da diese Namen sich bei mehreren Widgets (z.B. Buttons) ja sowiso überschneiden würden. Statt ``OnButton`` schreibe ich lieber ``show_infodialog`` oder ``get_sum``.
Wenn ich diese Methoden dann auch noch so definiere, dass nicht unbedingt ein Event übergeben werden muss, dann kann ich diese Methoden so auch noch verwenden.

Code: Alles auswählen

def show_infodialog(self, event = None):
    """
    Zeigt die Info-Dialogbox an.
    """
    pass
lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Leonidas hat geschrieben:Ich bin einer der wxPython-API-Flüchtlinge ;) Liegt aber nicht am CamelCase, sondern an der C++ness von dessen API, und (damals) an den Tonnen von Bugs.
Hi Leonidas!

Als ich mit Python anfing, hatte ich auch ein Auge auf wxPython geworfen. Allerdings konnte ich damals nichts mit der vorgezeigten Syntax vieler wxPython-Methoden und -Programme anfangen. Da gebe ich dir Recht. Das war wirklich schlimm und grausam zu programmieren.

Seit wxPython die neue Syntax eingeführt und zum Standard erhoben hat, ist wxPython den C++-Stil fast gänzlich los geworden. Jetzt macht es richtig Spaß, mit wxPython GUIs zu programmieren. Zumindest aus meiner Sicht.

- ``from wxPython.wx import *`` ist, zumindest aus meiner Sicht, STRENGSTENS VERBOTEN. Stattdessen gilt die neue Art ``import wx``.

- ``class MyApp(wxApp)`` ist nicht mehr nötig. ein einfaches ``app = wx.PySimpleApp()`` reicht und schon ist die Applikation initialisiert.

- ``def OnInit(self)`` kann man komplett weg lassen, wenn man möchte.

- Man kann jetzt mit ``Bind()`` ein Event an einen Event-Handler binden. Man muss nicht mehr den Umweg über das Event machen.

- ``SetTopWindow`` ist nicht notwendig. Es wird automatisch das erste Frame zum Haupt-Frame erhoben.

- ID´s werden nicht mehr gebraucht, da man mit ``Bind()``, Events auch an Objekte und nicht nur an ID´s binden kann.

Das ganze wxPython-Tutorial ist schei...

AnotherTutorial ist schon besser, auch wenn hie und da noch unnötig mit ID´s herumgefummelt wird.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Antworten