wxPython und PEP-8

[Michael Schneider]

Hallo,

ich lese mich gerade in wxPython ein und für mich als inzwischen trainierten PEP-8 Anwender ist dieser exzessive CamelCase-Missbrauch die reinste Netzhautpeitsche.

In einem parallelen Thread las ich von BlackVivi:

(In dem Code hab ich jetzt die Namenskonventionen gemischt, dass ist mir klar. Ich bin mir noch nicht sicher, wie ich es genau mache :/ Ich tendiere aber natürlich zu PEP8, obwohl wxPython sagt, dass man sich an der Namenskonvention von wx orientieren soll...)

So weit war ich in der wx-Doku noch nicht. Aber PEP-8 gibt es doch schon länger als wxPython und ich sehe keinen plausiblen Grund - wenn man schon einen Wrapper schreibt - nicht empfohlene Namenskonventionen einzuführen.

Es ist ja auch nicht immer so, dass ich ein Programm um wxPython umzu schreibe. Vielmehr gibt es das Programm manchmal schon und ich entwickle nur eine GUI dazu. Jedenfalls stoßen die beiden Konventionen früher oder später hart aufeinander, was mir überhaupt nicht gefällt!

Gibt es eventuell einen Wrapper, der eine PEP-8 konforme Anbindung zu wx bietet?
Und in welcher Konvention erweitert ihr von wxPython abgeleitete Klassen? Sprich: wo treffen bei euch die Konventionen aufeinander?

Bin mir noch nicht sicher, wie ich es machen sollte, darum bin ich sehr auf eure Lösungen gespannt.

Viele Grüße,
Michel

[Michael Schneider]

Erst einmal danke für eure Teilnahme an der Umfrage!

Bislang steht es 4 (selbst geschriebener Code in PEP-8) zu 2 (GUI Klassenerweiterungen in in wx-Konvention) zwischen den von mir favorisierten Lösungen.

Das ist eine wirklich verzwickte Situation. Wenn man bestimmte Methoden der Originalklassen "überschreiben" möchte, ist man ja gezwungen, PEP-8 zu ignorieren. Und wenn man mit PEP-8 ergänzt, hat man bald ein buntes Durcheinander.

Es ist wirklich schade, dass sich wxPython als Wrapper, der sich aus meiner Sicht nahtlos in die Zielsprache integrieren sollte, so querstellt. Aber zugegeben, PEP-8 ist nur eine Empfehlung. Dasselbe passiert immer, wenn einzelne Module unterschiedlichen Konventionen folgen, welche auch immer das sind.

[Dav1d]

du überschreibst Methoden?

[BlackJack]

@Michael Schneider: Bei den GUI-Toolkits hat man halt Wrapper um Bibliotheken in anderen Sprachen. Und es wird in der Regel die Namenskonvention des Originals übernommen, weil sinnvollerweise versucht wird so viel wie möglich zu automatisieren. Ist bei Qt ja zum Beispiel auch so.

Ich versuche es positiv zu sehen. Man kann immer in die Originaldokumentation schauen oder Infos über die Originalbibliothek im Netz suchen und findet dort immer die gleiche Namensgebung vor. Und man hat durch die Namen einen guten Hinweis wann man anfängt GUI und Logik zu vermischen, wenn man bei der Logik bei PEP8 bleibt.

[lunar]

Wenn ein Rahmenwerk wie PyQt4 oder wx einen anderen Stil verfolgt, dann halte ich mich bei Quelltext, der von diesem Rahmenwerk dominiert wird (insbesondere bei abgeleiteten Klassen) eher an die Namenskonvention des Rahmenswerks. Das ist konsistenter, und hat den Vorteil, dass sich Quelltext, der das Rahmenwerk tangiert, optisch von dem Quelltext unterscheidet, der das nicht tut. Natürlich wäre alles in PEP 8 schöner, aber so ist die Welt halt nicht.

Mich stört das auch nicht besonders. Ich bin verschiedenste Namenskonventionen aus verschiedenen Sprache gewöhnt, und habe keine Präferenz zu irgendeinem Stil. Wichtig ist nur, dass der Stil in sich konsistent und klar geregelt ist. An Schnittstellen zwischen Bibliotheken wird es so oder so immer Konflikte geben …

[gerold]

Hallo!

Schreibe alles nach PEP-8 Konvention...

... weil man so keine wxPython-Methoden überschreiben kann (zumindest nicht unabsichtlich). Das ist irgendwie eine schöne Trennung.

Wenn ich jetzt ein Erweiterungsmodul für wxPython schreiben würde, dann würde ich mich an die wxPython-Konventionen halten (müssen).

lg
Gerold

[Michael Schneider]

Moin!

du überschreibst Methoden?

Joa. Ich habe es nur in Anführungsstriche geschrieben, weil es bei Python eigentlich eine Überdeckung durch einen inneren Namespace ist. Aber im allgemeinen Sprachgebrauch nennt man es Überschreiben, wenn man in einer abgeleiteten Klasse eine Metode selben Namens definiert, die bei von Instanzen an Stelle der Originalmethode aufgerufen wird.

Wie schon gesagt: ich bin dennoch der Meinung, dass ein Wrapper, der ein Toolkit elegant in einen anderen Sprachkontext integrieren soll, auch dessen vorgeschlagenen Namenskonventionen berücksichtigen sollte. Das nicht zu tun halte ich für kurzsichtig und 'egoistisch'. Mag sein, dass aktuelle Programmierer, die mit wx vertraut sind, möglichst wenig Änderungen sehen möchten. Aber mit der Zeit gibt es immer neue Programmierer, die mit Python und nicht mit C++, C oder Cobol in die Programmierung einsteigen. Sie kennen wx in der Regel nicht und werden gleich mit Vermischungen von Namenskonventionen konfrontiert. Wie soll man ihnen da klar machen, dass es "guter Stil" ist, eben dies nicht zu tun?

@Blackjack: die Anwendung von PEP-8 hindert Dich nicht, in der Originaldokumentation nachzusehen. Du weißt ja, dass "set_pos" bei wx setPos ist. Das ist in meinen Augen kein starkes Argument.

Bestes Argument für eine Mischung ist die anzustrebende Trennung von Logik und GUI. Von daher halte ich es nun auch für das Sinnvollste, hier den Schnitt zu legen, wenn eine Mischung schon unvermeidbar ist.

Je nach Auto-Vervollständigen Funktion und Code-Explorer darf dann aber nicht innerhalb eines Namespace gemischt werden, also auch nicht auf Modulebene, oder?

Gruß,
Michel

[BlackJack]

@Michael Schneider: Bei der Umbenennung kann man aber immer Gefahr laufen Namenskonflikte zu bekommen. Es ist ja zum Beispiel möglich, dass ein Feld den Namen `foo` hat und auf dem Objekt auch eine Methode `Foo` besteht.

[Dav1d]

Wenn ich jetzt ein Erweiterungsmodul für wxPython schreiben würde, dann würde ich mich an die wxPython-Konventionen halten (müssen).

Vor dem Problem stehe ich gerade!

[Michael Schneider]

Hallo BlackJack,

@Michael Schneider: Bei der Umbenennung kann man aber immer Gefahr laufen Namenskonflikte zu bekommen. Es ist ja zum Beispiel möglich, dass ein Feld den Namen `foo` hat und auf dem Objekt auch eine Methode `Foo` besteht.

ich stecke noch nicht so ganz in der wxPython Konvention. Aber ich habe den Eindruck, dass auch dabei Attribute und Methoden die gleichen Namensregeln haben. Gehe mal davon aus, dass Du mit "Feld" ein Attribut eines Objekts meinst. Laut PEP-8 haben sie die auch.

Außerdem wird CamelCase laut PEP-8 nur für Klassen verwendet, wobei der erste Buchstabe groß geschrieben wird. Die Variante mit kleinen Anfangsbuchstaben habe ich in PEP-8 gar nicht gefunden.

Ich denke nicht, dass Du unrecht hast! Ich habe Dich nur noch nicht ganz verstanden.

Gruß,
Michael