Klassenname aus String (import, objekterzeugung)

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Xynon1
User
Beiträge: 1267
Registriert: Mittwoch 15. September 2010, 14:22

Nein, du liegst da völlig richtig, das war der Thread http://www.python-forum.de/viewtopic.php?f=18&t=25302. Das habe ich ja schon eingesehen, den Grund hatte ich auch schon mehrfach dort geschildert. Das ist hier aber ein anderer Fall - dort hatte ich im Grunde keine wirkliche Wahl, hier schon.
Die meisten von "Tkinter"s-Funktionen und Klassen bieten diese aber. Ich möchte das en für alle mal in meinen Schädel bekommen. Damit ich verstehe wann man nun die eine und wann die andere Vorgehensweise nutzen sollte.

Hier stellt sich mir auch die Frage, wenn ich von einem Tkinter-Widget erbe um andere Widgets anzubieten, soll ich dann auch beide Varianten anbieten?

Momentan sehen die Ableitungen bei mir immer so aus:

Code: Alles auswählen

class OtherWidget(tkinter.Widget):
    def __init__(self, master, cnf=()):
        tkinter.Widget(self, master, cnf)
Wenn ich die zweite Variante mit anbieten sollte, müsst es ja so aussehen:

Code: Alles auswählen

class OtherWidget(tkinter.Widget):
    def __init__(self, master, cnf=(), **kw):
        tkinter.Widget(self, master, cnf, **kw)
Sollte man das wirklich tun?
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst.
Xynon auf GitHub
lunar

@Xynon1: Ich habe in der Tat vergessen, verzeih mir. Mehr als "kommt darauf an" kann und will ich dazu aber eigentlich nicht sagen. Ich halte wenig von Dogmen, und würde insofern nur dazu raten, die Angelegenheit pragmatisch zu sehen. Wähle die Variante, welche Dir selbst am verständlichsten erscheint. Du musst Dich auch einfach auch mal auf Dein eigenes Urteilsvermögen verlassen, und eine bestimmte Entwurfsentscheidung vertreten können. Solange Du keine offensichtlich überzeugenden Argumente gegen diese Entscheidung ignorierst, wird Dir niemand einen Strick daraus drehen, wenn Du eine bestimmte Variante vorziehst, weil sie Dir selbst besser gefällt.

Ich persönlich würde bei Tkinter-Steuerelementen wohl Schlüsselwortargumente nutzen, aber für meinen Teil spricht auch nichts gegen die Übergabe eines Wörterbuchs. Allenfalls im Bezug auf die Diskussion, welche barabbas verlinkt hat, würde ich dauerbaustelle sofort zustimmen. Die Art, auf welche Du dort die Konfiguration übergibst, finde ich unschön, weil das Wörterbuch per se eigentlich vollkommen überflüssig ist. Die Gründe, welche Du dafür genannt hast, kann ich nicht nachvollziehen, aber das mag mithin an meiner Unkenntnis von Tkinter liegen.

Allerdings gibt es in dieser Diskussion auch Aussagen, die ich nicht unterschreiben würde, beispielsweise die, dass man Wörterbücher üblicherweise als Literalform und nicht über "dict()" erzeugt. Daraus würde ich auch kein Dogma machen wollen, und grob geschätzt kommen in meinem Quelltext beide Varianten mit etwa gleicher Häufigkeit vor.

Worauf ich also hinaus will, ist, dass man es auch übertreiben kann, sowohl mit dem Beharren auf "idiomatischem Python", bzw. dem, was man selbst dafür hält, als auch mit dem "sich an anderen orientieren".
Xynon1
User
Beiträge: 1267
Registriert: Mittwoch 15. September 2010, 14:22

@lunar
Das du es vergessen hattest, hatte ich mir ja schon gedacht :D
Danke für das Statement, im Grunde schon das was ich in Tkinter immer gemacht habe (bis auf das aus dem verlinkten Thread, welches wirklich nicht schön war) Ich versuche es dann nur in meiner API einheitlich zu halten und nicht so wie in der Tkinterlib.

Und "dict()"s welche ich zum initialisieren eines Dictionary genommen waren bisher immer einzeilig. Ich denke da spricht eigentlich nichts dagegen.
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst.
Xynon auf GitHub
Antworten