Ok, da gebe ich dir Recht. wxPython in Action ist wohl die Referenz (Hab nur gutes darüber gehört). Leider ist das komplett in Englisch und da mein Englisch nicht besonders gut ist, habe ich mir das dann auch nicht gekauft -- Durch englische Literatur kann ich mich auch im Web durchquälen und muss dafür nicht auch noch viel Geld ausgeben. Naja, bisher kam ich auch so an meine Informationen durch google, hier im erstklassigen Forum, durch die wxPython Demo und mit 80% ausprobieren.
Zur Demo von wxPython kann ich auch nur sagen das es erstklassig ist.
Schade, hätte ja sein können das du dazu auch ein Tipp hast. Den ich finde deine Möglichkeit mit dem wegfallen von IDs bei wxMenu nämlich Super und kannte das bisher nicht, da in der wxPython Demo auch IDs dafür benutzt benutzt werden.gerold hat geschrieben:Die Verwendung der ``wx.AcceleratorTable`` ist ein Fall, wo man nicht um die Verwendung von IDs herum kommt.sape hat geschrieben:wx.AcceleratorTable
Ok, von dieser Sicht aus betrachtet ist das ein sehr gutes Argument und werde ich mir daher auch nochmal durch den Kopf gehen lassen. Den glaube mir, ich habe sehr lange darüber nachgedacht nach welche Styleguide ich meine GUIs programmiere. Den von euch kamen damals **das für** mit PEP-8 und ich denke die Argumente sollte man dann auch konsequent weiterführen und für andere Sachen keine Ausnahme machen. Aber wie gesagt, ich werde darüber noch mal nachdenken.gerold hat geschrieben:Da bin ich deiner Meinung. Ich sage nur, dass ich mich beim Programmieren an PEP-8 halte. Dieser bleibe ich treu und werde nicht wegen einem anderen Styleguide, der mich persönlich total abschreckt, groß von PEP-8 abweichen. Der wxPython-Styleguide sollte eigentlich in die wxPython-Dev-Rubrik verschoben werden und nicht direkt von der Startseite aus zugänglich sein. Dieser wxPython-Styleguide macht mehr kaputt als gut. Dieser Stuileguide ist zu sehr an die Schreibweise der C++-Methoden angelehnt und zu weit von Python entfernt.sape hat geschrieben:Ich finde nicht, das man sich dann eine eigene Schreibkonvention anlegen sollte **nur** damit man nicht ausersehen eine Methode überschreibt.
Ok, da gebe ich dir teils Recht. Aber was machst du bei "richtigen" Eventmethoden die auch auf den Parameter ``event`` zurückgreifen und dort kein ``None`` erwarten sondern z.B. ein angeklicktes item von ``wx.ListCtrl``? Solch eine Methode ist dann nur in Verbindung mit einem vom Programm generierten Event benutzbar oder wenn man selber ein Event explizit generiert und es der Methode übergibt. Wegen diesem nicht sofort ersichtlichen Zustand, habe ich es mir angewöhnt meine Eventmethoden auch besonder zu kennzeichnen (Und ich benutze halt die "Auszeichnung" auf die sich alle geeinigt haben.). Und wenn eben eine Funktionalität unabhängig von einem Event genutzt werden kann, schreibe ich eine Methode dafür. Falls ich diese Methode halt auch im Event benötige, kommt es halt in eine ``On``-Event Methode rein. Damit komme ich am besten klar und finde es für mich übersichtlicher.gerold hat geschrieben:Niemand wird mich davon abhalten. Ich programmiere jetzt seit 21 Jahren und habe meinen Stil immer wieder angepasst, um besseren, durchschaubareren und wartbareren Code zu produzieren. -- Nach meiner Erfahrung, gibt es absolut keinen Grund für mich, einen Event-Handler besonders zu kennzeichnen. Es genügt, wenn als zweiter Parameter ``event`` erwartet wird. Im Gegenteil! Bei vielen Programmen, hat man nur mehr Schreibarbeit und absolut keinen Zusatznutzen. Was bringt es mir zehn Event-Handler zu schreiben, die nichts anderes tun, als eine einzige Methode aufzurufen. Da schreibe ich diese einzelne Methode doch lieber so um, dass diese als Event-Handler verwendet werden kann, als dass ich zig Methoden erzeuge, deren einziger Zweck eine Weiterleitung zur richtigen Methode ist! Wenn es auch nur ansatzweise mehr Durchschaubarkeit des Codes bringen würde, dann würde ich es machen, aber nachdem ich beide Schreibweisen ausprobiert und abgewägt habe, bleibe ich bei meiner Aussage, dass besonders benannte Event-Handler (z.B. OnCloseWidget1 oder OnClickButton2) keinen zusätzlichen Vorteil bringen.sape hat geschrieben:Nein macht es nicht!gerold hat geschrieben:Es macht viel mehr Sinn, eine Methode, die ein Frame schließt "close_frame" zu nennen.
Neingerold hat geschrieben:Es hindert dich ja niemand daran.sape hat geschrieben:Wenn ich eine Methode habe die auch so benutzt werden kann und von einem Event, dann schreibe ich die Methode z.B. ``FillBooklist``. So wenn nun ein Event auch dafür zuständig sein soll, da schreibe ich eine Eventmethode die ``FillBooklist`` aufruft.
Naja, sagen wir es mal so: Die meisten fassen ja Methoden/etc die mit einem unterstrich oder zwei unterstrichen beginne nicht an, weil es suggerieren soll das es privat ist und nur für interner relevant ist. Bei Eventmethoden verhält es sich "ähnlich" (Ok, die Analogie hinkt ein wenig).gerold hat geschrieben:Den verstehe ich nicht.sape hat geschrieben:Um eine Analogie herbeizuführen: Keiner Benutzt "Private"-Methoden (_ und __ am Anfang) oder? Genauso verhält es sich auch mit einer Eventmethode...
Die Konvention sagt, das man eine Eventmethode nur explizit aufrufen sollte, wenn man dem Event-Parameter auch ein Event übergibt:
Beispiel:
Code: Alles auswählen
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import os
os.path
import wx
wx.SetDefaultPyEncoding("utf-8")
class WidgetFoobar(wx.Panel):
def __init__(self, parent):
wx.Panel.__init__(self, parent)
self.textCtrl = wx.TextCtrl(self, -1, "", size=(300, -1))
self.Bind(wx.EVT_TEXT, self.OnTextCtrlEdit, self.textCtrl)
vbox = wx.BoxSizer(wx.VERTICAL)
vbox.Add(self.textCtrl, 0, wx.EXPAND|wx.ALL, 5)
self.SetSizer(vbox)
def OnTextCtrlEdit(self, event):
return self.textCtrl.GetValue()
class MainFrame(wx.Frame):
def __init__(self, parent=None, id=-1, title = "MyApp"):
wx.Frame.__init__(self, parent, id, title)
self.Centre()
self.panel = wx.Panel(self)
self.widgetFoobar = WidgetFoobar(self.panel)
self.widgetFoobar.Bind(wx.EVT_TEXT, self.OnTextCtrlEdit)
def OnTextCtrlEdit(self, event):
# Ist OK, da ich die Eventmethode mit einem Event aufrufe.
# In dem Fall leite ich das Event nur um.
value = self.widgetFoobar.OnTextCtrlEdit(event)
print value
# Sonstiges mit dem aufgefangen wert machen...
def main():
app = wx.PySimpleApp()
mf = MainFrame()
mf.Show()
app.MainLoop()
if __name__ == "__main__":
main()