Diskussion zu PEP8!

[sape]

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]

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.

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.

[sape]

Danke. Ich werde mir GTK anschauen

lg

[gerold]

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.

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

[gerold]

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

[Y0Gi]

Zum Thema Funktions- und Methodennamen:
Da diese *immer* ein Verb sein sollten (z.B. get..., reload..., parse...; auch wenn das in diversen uralten C-Libs nicht der Fall ist), ist es sowohl im Englischen als auch Deutschen nur konsequent und logisch, diese klein zu schreiben. Außerdem werden sie dadurch sehr gut von Klassennamen unterscheidbar, die man traditionell (soweit mir bekannt) groß schreibt (ok, zugegeben, Nomen schreibt man im Englischen klein, aber hey).

Ob man Erstgenannte allerdings mixedCase oder underscore_separated schreibt, ist noch am ehesten Geschmackssache. Ersteres habe ich so aus der Java-Welt übernommen, wo es eigentlich in der Regel ganz ordentlich und lesbar ist. Ausnahme sind dann Namen, die Abkürzungen oder Akronyme wie XML, HTTP oder dergleichen enthalten; sowohl getXMLData als auch getXmlData sind beide nicht ganz der Weisheit letzter Schluss. An dieser Stelle spielt die Underscore-Variante ihre Stärken aus, fordert dafür aber minimal mehr Zeichen für die zusätzlichen Unterstriche ein.
Da man in beiden Fällen fast gleich oft die Shift-Taste bemühen muss, ist der Unterschied vom Aufwand beim Tippen vernachlässigbar klein.


gerold: Auch du könntest den Apostroph bitte vorbildlich verwenden. Bei "ID´s" anstelle des korrekten "IDs" apostrohpierst du nicht nur fälschlicherweise, sondern verwendest auch noch einen französichen Akzent (´) anstelle des Apostroph-Zeichens ('). Nix für ungut

[BlackJack]

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

Warum ist das der letzte Punkt Deiner Aufzählung? Diese IDs waren damals der Grund warum ich schreiend weggelaufen bin als ich wxWindows ausprobiert hatte. Zu jedem Objekt eine ID erzeugen und die stellvertretend in der Gegend herum zu reichen ist mir sowas von unpythonisch, aufwändig und überflüssig erschienen...

[gerold]

der Grund warum ich schreiend weggelaufen bin

-- das kann ich mir ziemlich gut vorstellen.

lg
Gerold

[sape]

Hi gerold:
Zum post vom Do Nov 09, 2006 23:03: Interessanter Ansatz und mMn auch sehr gut So weit hatte ich nicht gedacht. Das werde ich mit übernehmen. Danke

...

Warum keine IDs? Sollte ich die auch vermeiden und stattdessen lieber ein -1 setzen?

Ich mache immer nen Konstante zb. WXID_IRGENDWAS und mache dann ein wx.NewId(), das mir selber eine ID erzeugt -> WXID_IRGENDWAS = wx.NewId().

Danach übergebe ich das dann. Also doch lieber ein -1 übergeben?

[gerold]

Ich mache immer nen Konstante zb. WXID_IRGENDWAS und mache dann ein wx.NewId(), das mir selber eine ID erzeugt -> WXID_IRGENDWAS = wx.NewId().

Hi XtraNine!

Hier ein Beispiel, ohne Ids:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import wx

wx.SetDefaultPyEncoding("iso-8859-1")


class MyFrame(wx.Frame):
    
    def __init__(self, parent = None, id = -1, title = "Hallo Welt (ohne IDs)"):
        
        wx.Frame.__init__(self, parent, id, title)
        
        # Panel
        panel = wx.Panel(self)
        
        # Hauptrahmen (fuer den Abstand)
        vbox_rahmen = wx.BoxSizer(wx.VERTICAL)
        panel.SetSizer(vbox_rahmen)
        
        # vbox (innherhalb des Hauptrahmens mit 5px Abstand)
        vbox = wx.BoxSizer(wx.VERTICAL)
        vbox_rahmen.Add(vbox, proportion = 1, flag = wx.ALL | wx.EXPAND, border = 5)
        
        # Label
        label = wx.StaticText(
            panel, -1, u"Ich werde geändert, wenn der Button geklickt wird!",
        )
        self.label = label
        vbox.Add(label, proportion = 1, flag = wx.ALL, border = 5)
        
        # Button
        button = wx.Button(panel, -1, "Klick mich!")
        vbox.Add(button, proportion = 0, flag = wx.ALL | wx.EXPAND, border = 5)
        button.Bind(wx.EVT_BUTTON, self.aendere_labeltext_per_button) # Eventhandler binden
        
        # Menüleiste
        menubar = wx.MenuBar()
        
        # Hilfe-Menü
        menu_help = wx.Menu()
        menuitem = menu_help.Append(-1, "&Info")
        # Ausnahme! Menüs müssen über das Frame-Objekt an ein Event gebunden werden.
        self.Bind(wx.EVT_MENU, self.aendere_labeltext_per_menue, menuitem)
        menubar.Append(menu_help, "&Hilfe")
        
        # Menüleiste an Frame binden
        self.SetMenuBar(menubar)
        
        # Minimalgröße festlegen 
        panel.Fit()
        self.Fit()
        self.SetSizeHintsSz(self.GetSizeTuple())
        
        # Zentrieren
        self.Center()
    
    
    def aendere_labeltext_per_button(self, event = None):
        
        label = self.label
        label.SetLabel(u"Es wurde der Button geklickt!")

    
    def aendere_labeltext_per_menue(self, event = None):
        
        label = self.label
        label.SetLabel(u"Es wurde das Info-Menü ausgewählt!")


def main():
    
    app = wx.PySimpleApp()
    f = MyFrame()
    f.Show()
    app.MainLoop()


if __name__ == "__main__":
    main()

lg
Gerold

[oliver1974]

Mein erster Post hier im Forum und dann gleich mal hier voll einsteigen...


An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Das ist SEHR kurz, wie ich finde.....

... einige Sachen wie TreeViews sind auch in PyGTK unnötig komplex.

Ja, das GTK-TreeView.... Ich hab mich auch vor kurzem am Kopf gekratzt
und gedacht: "...ich will doch nur einen stinknormalen Tree.... Und
ein paar Spalten!!"

Hammer auch, das die "Tabelle" ein Sonderfall vom Tree ist
(hab ich doch jetzt richtig in Erinnerung, oder?), da muss man
erstmal drauf kommen.... Da sucht man sich ja erst dumm und dämlich!

Überhaupt, Tutorials und GUI-Apis unter Pyhton scheinen so ein
Thema zu sein, auch das PyGTK-Tutorial ist nicht mehr so Up-To-Date,
an manchen Stellen fliegen einem ja beim Nachprogrammieren
nur so die "deprecation warnings" um die Ohren.

Irgendwie scheint mir da echt eine "Marktlücke" zu sein, oder... ?

[Y0Gi]

An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Ja, allerdings. Und ich finde, das klappt recht problemlos, insbesondere wenn man Klassen- und Methodennamen nicht mehr als 40 Zeichen spendiert, wie das in der Java-Welt ja nichts ungewöhnliches ist. Und irgendwann muss man sowieso umbrechen, das geht dann auch bei Spalte 80 (bzw. 79) nicht wirklich schlechter.


Ich weiß nicht, wieso das hier so GUI-Toolkit-lastig (sprich: OT) ist, aber wo wir schon dabei sind...

Überhaupt, Tutorials und GUI-Apis unter Pyhton scheinen so ein Thema zu sein, auch das PyGTK-Tutorial ist nicht mehr so Up-To-Date, an manchen Stellen fliegen einem ja beim Nachprogrammieren nur so die "deprecation warnings" um die Ohren.

Irgendwie scheint mir da echt eine "Marktlücke" zu sein, oder... ?

Beim Lernen von wx bin ich auch über viel, ja, unbrauchbaren oder wertlosen Code gestolpert. Das mag aber daran liegen, dass diese API (und das mag auf andere, außer vielleicht die von Tkinter, wohl auch zutreffen) umfangreich geändert wurde. IDs und diverse Initialisierungen wurden überflüssig usw. Für Neueinsteiger ist der jeweils aktuelle Zustand der API sicherlich eine bessere Ausgangsposition, aber das Vorhandensein von nun unbrauchbarem Code ist natürlich ein unangenehmer Trade-Off.

[oliver1974]

An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Ja, allerdings. Und ich finde, das klappt recht problemlos, insbesondere wenn man Klassen- und Methodennamen nicht mehr als 40 Zeichen spendiert, wie das in der Java-Welt ja nichts ungewöhnliches ist. Und irgendwann muss man sowieso umbrechen, das geht dann auch bei Spalte 80 (bzw. 79) nicht wirklich schlechter.

Hmm, ich benutze eigentlich nicht gerade mega-lange Klassen- und
Methodennamen, trotzdem finde ich es doch recht störend,
alle naselang umzubrechen, schließlich hat man ja in der
Regel auch beträchtliche Einrückungen.

Ich bin da echt drauf und dran, in diesem Zusammenhang die PEP8
zu ignorieren.... Abgesehen vom Stilbruch, was hat es sonst
für negative Auswirkungen?

Heute fährt doch kaum einer Auflösungen, wo eine Zeile mit 90 - 100 Zeichen ein Problem darstellt, oder?
Abgesehen natürlich von den Leuten mit Sehproblemen, die lieber generell
große Fonts und eventuell eine insgesamt niedrigere Auflösung bevorzugen...

[birkenfeld]

"Stilbruch" ist eher schon zu dramatisch gesagt . 90 Zeichen ist IMO sehr vernünftig, gerade in Code, der etwas verschachtelter ist.

[gerold]

Heute fährt doch kaum einer Auflösungen, wo eine Zeile mit 90 - 100 Zeichen ein Problem darstellt, oder?

Hi oliver!

Du übersiehst da ein paar Dinge:

- Viele verwenden eine IDE und nicht nur einen reinen Editor zum Entwickeln. An den Seiten sind in den meisten IDEs Tool-Fenster eingeblendet, die beim Entwickeln helfen. Z.B. ein Fenster in dem die Klassen und Funktionen des gerade bearbeiteten Moduls angezeigt werden. Oder z.B. ein Code-Assistent, der ständig Informationen über die aktuellen Attribute aufzeigt... Da ist man froh, wenn die anderen ihren Code so um die Spalte 80 herum umgebrochen haben, damit man diesen komplett lesen kann.

- Wenn du Code ins Python-Forum einfügst, dann hast du in der Anzeige auch nicht die volle Breite zur Verfügung. Als Richtwert für den Zeilenumbruch die Spalte 80 zu verwenden ist auch hier nicht unbedingt eine schlechte Idee. Es stört niemanden, wenn mal eine Zeile ein wenig länger ist. Aber die Ausnahme sollte nicht zur Regel werden.

- Nicht jeder entwickelt immer in einem Fenster das die volle Breite des Screens ausnutzt. Viele haben mehrere Fenster offen, um während des Entwickelns den Code schnell mal testen zu können und/oder sofort die Auswirkungen des geänderten Codes anzeigen zu lassen. Auch hierfür ist man froh, wenn sich alle am Projekt beteiligten Entwickler an die 80 Zeichen halten.

Das sind mir fürs Erste genug Gründe um 80 Zeichen als Richtwert für den Zeilenumbruch zu verwenden.

mfg
Gerold

[oliver1974]

Hi Gerold!

Das sind schon mal durchaus gute Gründe.

Ich benutze ansonsten auch eine IDE (Eclipse) für Java
(das Python Plug-In muss ich noch testen!), aber generell
habe ich da einen anderen Geschmack, bevor ich mir Zeilenumbrüche
antue, scrolle ich lieber.. ist durchaus der Regelfall, wenn man,
wie du schon erwähntest, mehrer Fenster nebeneinander hat.

Scheint jetzt irgendwie Geschmackssache zu sein, mich hat
das scrollen weniger gestört als das "zerreissen" der lines.

Na ja, mal sehen wie ich in Zukunft mit den 80 Zeichen zurecht komme...

[N317V]

80 Zeichen ist die Standardbreite von Unix-Terminals.

[jens]

An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Ja... Auch wenn ich PyLucid noch einige längere Zeilen stecken, aber das sind meist alte Codezeilen
Ansonsten beschränke ich mich auf 80 bzw. 79 Zeichen, seid dem ich weiß wie man in SciTE eine vertikale Linie an der Stelle hinsetzten kann:

# Vertikale Linie zur Textberenzung auf 79 Zeichen
edge.column=79
edge.mode=1
edge.colour=#dddddd

[gerold]

Scheint jetzt irgendwie Geschmackssache zu sein, mich hat das scrollen weniger gestört als das "zerreissen" der lines.

Hi oliver!

Das Umbrechen ist gar nicht so schwer wie viele glauben. Hier ein paar Beispiele, die aufzeigen wie ich lange Zeilen umbreche. Man muss es ja nicht so wie ich machen... -- soll nur eine Anregung sein.

Code: Alles auswählen

def meine_funktion(
    argument1, argument2, argument3, argument4,
    argument5 = None, argument6 = None
):
    if (
        argument1 == "langer Text" and 
        argument2 == "langer Text" and 
        argument3 == "auch ein langer Text"
    ):
        message = (
            "Das ist die perfekte Welle. Das ist der perfekte Tag. "
            "Das ist die perfekte Welle. Das ist der perfekte Tag. "
            "Das ist die perfekte Welle. Das ist der perfekte Tag. "
            "Das ist die perfekte Welle. Das ist der perfekte Tag.\n"
            "Wir sind gekommen um zu bleiben. Wir sind gekommen um zu bleiben.\n"
            "Wir sind gekommen um zu bleiben. Wir sind gekommen um zu bleiben.\n"
        )
        return message
    else:
        return "Hallo Welt"

a = meine_funktion(
    argument1 = "Das ist langer Text", # hier kann auch eine Bemerkung stehen
    argument2 = "Das ist langer Text", 
    argument3 = "Das ist langer Text", # hier kann auch eine Bemerkung stehen
    argument4 = "Das ist langer Text", # hier kann auch eine Bemerkung stehen
)
print a

mfg
Gerold

[jens]

Ich würde es ähnlich machen, allerdings nicht bei der funktions definition und nicht beim if... Ich mache es dann ehr mit einem "\":

Code: Alles auswählen

def meine_funktion(argument1, argument2, argument3, argument4, \
                                        argument5 = None, argument6 = None):
                                            
    if (argument1 == "langer Text" and argument2 == "langer Text" and \
                                        argument3 == "auch ein langer Text"):

Wobei das auch nicht ganz so aufgeräumt aussieht... Aber ich finde das "):" alleine auf einer Zeile irgendwie komisch.