gerold hat geschrieben:
sape hat geschrieben:die Dokumentation zu einem Widgets ist so knapp, das man um das herumprobieren nicht herum kommt
wxPython lässt sich super programmieren, wenn man eine IDE mit guter Codevervollständigung benutzt. Ich verwende WingIDE, aber auch Eclipse soll nicht schlecht sein.
Ja kann Eclipse auch. Das hat aber nichts mit der Dokumentation zu tun.
gerold hat geschrieben:
Ich brauche so gut wie keine Dokumentation, da mir WingIDE im richtigen Augenblick die möglichen Methoden, die zu übergebenden Parameter und deren Docstrings anzeigt. Wenn ich mal nicht weiß, wie ich etwas an einem Widget ändern kann, dann gehe ich die Liste der Methoden durch und weiß, da die Methodennamen aussagekräftig sind, nach wenigen Sekunden, welche Methode ich dafür brauche. Wenn ich unschlüssig bin, dann schaue ich kurz in die wxWidgets-Dokumentation.
Naja, bei vielen dingen muss man aber wissen wie man die Sachen richtig verwendet -> z.B.: wx.ListCtrl, wx.aui, etc. Alles dinge deren Benutzung mir nicht *so* offensichtlich war. Was ich damit sagen will ist, das es nicht genügt anhand der Namen der Methoden darauf zu schließen wie man das komplette Widget "richtig" benutzt.
gerold hat geschrieben:
wx.aui ist komplett neu und wird derzeit noch entwickelt. Das ist zwar nicht schlecht, aber wer sich auf so neue Techniken einlässt, muss schon mal Abstriche machen.
Ehm es gibt Widgets die schon lange benutzt werden und **nicht neu** sind und eine wirklich schlechte Dokumentation haben. Daher hinkt dein Argument gewaltig. 80% der Dokumetation ist einfach schrott. Wenn ich mir dagegen die Dokumentation von pyGTK anschaue...Da ist die Dokumentation von wx Lichtjahre entfernt.
gerold hat geschrieben:
Dann gibt es aber auch noch Widgets, die kaum jemand einsetzt und auch nicht plattformübergreifend verwendbar sind, wie z.B. das wx.lib.iewin, das eine einfach gestrickte Möglichkeit darstellt, den den Internet Explorer als Widget einzubinden. Dabei wurde einfach nur das IE-Control als ActiveX-Control eingebunden. Wenn jemand wissen will, wie dieses IE-Control programmiert werden kann, der kann sich in der Windows-PlattformSDK schlau machen.
Jepp, nach dem studieren der Sourcecodes weiß ich das auch, das iewin nur ein ActiveX-Con wrappt.
Denoch wäre es **nicht schelcht**, wenn zu mindest das iewin Modul in der von Epydoc generierten Dokumentation auftauchen würde.
gerold hat geschrieben:
sape hat geschrieben:In einigen wenigen fällen muss man sogar im Sourcecode schauen
Im WingIDE klicke ich mit der rechten Maustaste auf ein Objekt und dann auf "Gehe zur Definition". Schon bin ich im wxPython-Quellcode, genau an der Stelle, an der das markierte Objekt erstellt wurde. Das ist eine Dokumentation nach meinem Geschmack.
Ja, geht auch in Eclipse
BTW: Das ist keine "Dokumentation" nach meine Geschmack. Du wilslt doch den Vorgang "In den Source schauen was für Methoden Objekt X hat" nicht als Dokumentation bezeichnen?!
gerold hat geschrieben:
sape hat geschrieben:In wenigen "speziellen" fällen ist man immer noch darauf angewiesen IDs rumzureichen bzw. zu erstellen, was aber anders nicht zu lösen ist. Dennoch nervig -> z.B.:``wx.Menu``
Das stimmt nicht:
Code: Alles auswählen
menubar = wx.MenuBar()
mnu_file = wx.Menu()
mnu_f_exit = mnu_file.Append(-1, "E&xit")
self.Bind(wx.EVT_MENU, lambda event: self.Close(), mnu_f_exit)
menubar.Append(mnu_file, "&File")
self.SetMenuBar(menubar)
Ok, das man das Item direkt angeben kann, wusste ich nicht.
Baer hier ist das nicht möglich (oder?):
Code: Alles auswählen
acell_id1 = wx.NewId()
accel = wx.AcceleratorTable([
# Applikation beenden
(wx.ACCEL_CTRL, wx.WXK_F4, acell_id1),
(wx.ACCEL_CTRL, ord('Q'), acell_id1)
])
self.SetAcceleratorTable(accel)
def OnClose(event):
self.Close()
self.Bind(wx.EVT_MENU, OnClose, id=acell_id1)
gerold hat geschrieben:
sape hat geschrieben:-- Das alles CamelCase ist finde ich nicht so gut.
Es stört mich zwar auch, aber ich nutze es als Vorteil aus. Die wxPython-Methoden sind mit CamelCase-Namen benannt. Ich schreibe alle Methoden klein.
Das ist aber kein Argument. Ich finde man sollte sich schon daran halten so wie man sich beim Logischen Teil an PEP-8 hält. Wenn dabei ein Widget rauskommt das vielleciht auch anderen nützlich ist, finde ich es sehr strange damit zu arbeiten weil das alle Konventionen nicht einhält. -- Widgets die sich nicht am Syleguide halten werden z.B. auch nicht im wxPython-"Core" aufgenommen und das zu recht. Genauso wie Python Module die sich nicht an PEP-8 halten auch nicht in die Batteries aufgenommen werden (Ok, die existierenden Ausnahmen lassen wir mal beiseite. In Py3k wird ehe ordentlich ausgemistet.)
gerold hat geschrieben:
Somit kann ich nicht unabsichtlich wxPython-Methoden überschreiben.
Dann sollte man besser aufpassen, ernsthaft! Wenn du von Klasse X aus Package Y erbst (Sagen wir mal als Beispiel einen Lexer aus Pygements den man als Base nimmt), muss du doch auch aufpassen(?). Ich finde nicht, das man sich dann eine eigene Schreibkonvention anlegen sollte **nur** damit man nicht ausersehen eine Methode überschreibt.
gerold hat geschrieben:
Auch wenn ich mal eine close-Methode definiere, überschreibe ich damit nicht die eingebaute Close-Methode. Der wxPython-Styleguide ist, meines Erachtens, nur für die gedacht, die wxPython erweitern. Für die, die wxPython als Framework benutzen, ist er (meiner Meinung nach) Schwachsinn.
Nein der ist nicht Schwachsinn. Guter Stil ist nie Optional. PEP-8 ist **auch** nur dazu da, damit eigene Source in den Batteries aufgenommen werden können. Daher ist das keine wirkliche Begründung von dir. Ich behaupte mal das die Meisten die wxPython nutzen sich auch am Styleguid halten, genauso wie sich auch die meisten an PEP-8 halten. Und beides aus gleichen gründen.
gerold hat geschrieben:
Was soll die Verwendung von CamelCase innerhalb des Programms bringen? Was soll die Benennung von Event-Handlern mit z.B. "OnClose" oder "OnClick"? Es macht viel mehr Sinn, eine Methode, die ein Frame schließt "close_frame" zu nennen.
Nein macht es nicht!
gerold hat geschrieben:
Oder eine Methode, die mir eine Liste mit Werten füllt, werde ich nicht "OnClick" nennen. Diese wird z.B. "fill_booklist" genannt. Auf so eine Methode kann ich auch außerhalb des Event-Systems von wxPython zugreifen. Deshalb schreibe ich solche Event-Handler auch so, dass sie auch dann funktionieren, wenn ich das Event nicht mit übergebe.
Event-Methoden sollten alle mit einen "On" am Anfang beginnen. Und das hat auch zwei Gründe von dem sich der eine Übersichtlichkeit nennt. An dem "On" erkenne ich und andere sofort das es sich um eine Methode handelt die Events entgegennimmt. Und das ist der zweite Grund der dazu führt das es einem Signalisiert "Halt nicht selber aufrufen, dann Eventmethoden ruft man nicht selber auf".
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.
Den es ist **absolut** unkonventionell Eventmethoden Explizit aufzurufen. Wenn man deren Funktionalität benötigt lagert man das in eine Separate Methode aus, und ruft sie dann von der Event Methode aus auf. Und wenn die Abarbeitung einer Eventmethode vom Event-"Status", etc. abhängig ist und man dennoch so eine Eventmethode Explizit aufrufen möchte (Was ja nicht geht es sei man generiert selber ein Event und übergibt das der Methode.), dann liegt ein genereller Designfehler vor. Das heißt, die Sachen in der Eventmethode die auch separat Funktionsfähig sind, sollte man immer in einer separaten Methode auslagern.
Code: Alles auswählen
class ...
...
def FillBooklist(self):
pass
def OnClickBooklist(self, event):
self.FillBooklist()
Um eine Analogie herbeizuführen: Keiner Benutzt "Private"-Methoden (_ und __ am Anfang) oder? Genauso verhält es sich auch mit einer Eventmethode...
BTW: Zu dem Thema der Dokumentaiotnsqualität von wxPython - Gerold sei mir nicht böse, aber ich finde mal sollte auch Objektiv bleiben. Ich finde deine Argumente bezüglich wxPython Dokumentation sind nicht wirklich Objektiv. Die Dokumentation ist wirklich schwach und da kannst du noch soviel schreiben wie man die Mängel "umgehen" kann, das ändert nichts an der Tatsache.
Wie du und ihr wisst, ist wxPython auch mein Favorit und nutze es auch gerne. Aber ich sehe nicht ein die Schwächen von wxPython mit schwachen Argumenten zu rechtfertigen!
