Seite 1 von 3

Verfasst: Donnerstag 9. November 2006, 18:32
von 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 ^^

Verfasst: Donnerstag 9. November 2006, 18:57
von Leonidas
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.

Verfasst: Donnerstag 9. November 2006, 19:01
von sape
Danke. Ich werde mir GTK anschauen :)

lg

Verfasst: Donnerstag 9. November 2006, 22:03
von gerold
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
:-)

Verfasst: Donnerstag 9. November 2006, 22:23
von gerold
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
:-)

Verfasst: Freitag 10. November 2006, 11:41
von 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 :)

Verfasst: Freitag 10. November 2006, 12:47
von BlackJack
gerold hat geschrieben:- 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...

Verfasst: Freitag 10. November 2006, 14:14
von gerold
BlackJack hat geschrieben:der Grund warum ich schreiend weggelaufen bin
:lol: -- das kann ich mir ziemlich gut vorstellen.

lg
Gerold
:-)

Verfasst: Freitag 10. November 2006, 15:31
von 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?

Verfasst: Freitag 10. November 2006, 16:39
von gerold
XtraNine hat geschrieben: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
:-)

Verfasst: Montag 13. November 2006, 07:25
von oliver1974
Mein erster Post hier im Forum und dann gleich mal hier voll einsteigen...
:wink:

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

Das ist SEHR kurz, wie ich finde.....
Leonidas hat geschrieben: ... 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... ?

Verfasst: Montag 13. November 2006, 08:03
von Y0Gi
oliver1974 hat geschrieben: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...
oliver1974 hat geschrieben:Ü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.

Verfasst: Montag 13. November 2006, 08:19
von oliver1974
Y0Gi hat geschrieben:
oliver1974 hat geschrieben: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...

Verfasst: Montag 13. November 2006, 09:11
von birkenfeld
"Stilbruch" ist eher schon zu dramatisch gesagt ;). 90 Zeichen ist IMO sehr vernünftig, gerade in Code, der etwas verschachtelter ist.

Zeilenumbruch bei 80 Zeichen

Verfasst: Montag 13. November 2006, 09:15
von gerold
oliver1974 hat geschrieben: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
:-)

Verfasst: Montag 13. November 2006, 09:21
von 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...

Verfasst: Montag 13. November 2006, 09:33
von N317V
80 Zeichen ist die Standardbreite von Unix-Terminals.

Verfasst: Montag 13. November 2006, 09:36
von jens
oliver1974 hat geschrieben: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
:lol:

Verfasst: Montag 13. November 2006, 09:38
von gerold
oliver1974 hat geschrieben: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
:-)

Verfasst: Montag 13. November 2006, 10:22
von 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.