OOP Fragen

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.
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

Seit gegrüßt,

die ganze Geschichte in OOP in Python is doch bissl komplizierter als ich dachte.
In PHP war es für mich leichter zu verstehen wie OOP dort funktioniert als in Python.

Ich wollte erstmal das Login Formular/Skript/Programm oder wie man es
auch immer nennen umsetzen, was bis jetzt auch funktioniert.
Sprich Formular/Skript/Programm wird aufgerufen.
Die Eingabefelder sind da, Beschriftung und zwei Buttons für Login und Schließen.

Schließen funktioniert ohne zu meckern und auch sonst bekomm ich keine Fehler.
Ich wollte mir per "print" mir das ausgeben lassen was ich in die Eingabefelder eingegeben
habe nur leider bekomm ich keine Ausgabe in der Konsole, sprich kein Zeichen. Bleibt einfach leer

Hier der Code dazu:

Code: Alles auswählen

__author__ = 'gast'
from gi.repository import Gtk
from gi.repository import Pango
import tkinter
import tkinter.ttk
import tkinter.messagebox
import psycopg2
from tkinter import *
from tkinter.ttk import *
import os

root = Tk()
root.title('WBS')

class Application(Frame):

    def __init__(self, master):
        Frame.__init__(self, master)
        self.grid()
        self.login()
        self.layout()

    def layout(self):
        Button(text = "Login", command = self.login).grid(row=5, column=0, sticky=NSEW, pady=4)
        Button(text='Schließen', command = self.master.quit).grid(row=5, column=1, sticky=NSEW, pady=4)


    def login(self):

        root.protocol("WM_DELETE_WINDOW", self.master.quit)
        connection = psycopg2.connect("dbname=sqltest")
        cursor = connection.cursor()

        Label(text="Username", font="Helvetica 13 bold").grid(row=4, column=0, pady=5, padx=5)
        Label(text="Passwort", font="Helvetica 13 bold").grid(row=4, column=1, pady=5, padx=5)


        benutzername = Entry(font=10)
        benutzername.grid(row=3, column=0, padx=5, pady=5)

        passwort = Entry(font=10, show="******")
        passwort.grid(row=3, column=1, padx=5, pady=5)

        cursor.execute("SELECT * FROM mitarbeiter WHERE loginname = %s AND passwort = %s ", (benutzername.get(), passwort.get()))
        row = cursor.fetchone()

        print(benutzername.get())
        print(passwort.get())

        # benutzername.delete(0, END)
        # passwort.delete(0, END)

        # if row is not None:
        #     self.master = Frame(root, name='master') # create Frame in "root"
        #     self.master.pack(fill=BOTH) # fill both sides of the parent
        #     self.nb = Notebook(self.master, name='nb', width=1200, height=450) # create Notebook in "master"
        #     self.nb.grid(row=6, column=2) # fill "master" but pad sides
        #
        #     #Tab Master hinzufügen
        #     self.tab_kunde_neu = Frame(self.nb, name='tab-kunde-neu')
        #     self.nb.add(self.tab_kunde_neu, text="Kunde (neu)")
        #     self.tab_kunde = Frame(self.master, name='tab-kunde')
        #     self.nb.add(self.tab_kunde, text="Kunde")
        #     self.tab_vermittler_neu = Frame(self.nb, name='tab-vermittler-neu')
        #     self.nb.add(self.tab_vermittler_neu, text="Vermittler (neu)")
        #     self.tab_vermittler = Frame(self.nb, name='tab-vermittler')
        #     self.nb.add(self.tab_vermittler, text="Vermittler")

app = Application(root)
root.mainloop()
Meine Frage jetzt dazu:
Liegt es daran das die Eingabe nach dem drücken des Login-Buttons gelöscht wird bevor
überhaupt die Eingabe ausgegeben werden kann oder wird die Eingabe gar nicht erst
"zwischengespeichert" ?
BlackJack

@Kalli87: Das liegt daran das Du die Eingabefelder erstellst und dann sofort danach den Inhalt ausgibst. Dann sind die natürlich noch leer, denn der Benutzer hatte ja noch überhaupt keine Zeit dort etwas einzugeben. Die Möglichkeit bekommt der Benutzer erst wenn die GUI-Hauptschleife läuft.

Der Code in den Methoden ist komisch aufgeteilt. Die `__init__()` sollte Code enthalten der das Objekt initialisiert. Nichts weiter, also bei GUI-Objekten die GUI beziehungsweise den GUI-Teil den das Objekt repräsentiert zur Anzeige vorbereiten und dann zurück kehren, damit der Aufrufer entscheiden kann was genau er damit dann tut. Ausserhalb der `__init__()` sollten keine neuen Attribute eingeführt werden und die Attribute sollten zusammen den Zustand des Objekt ausmachen, nicht mehr, aber auch nicht weniger.

Die Methodenaufrufe sind auch eigenartig — es wird `login()` aufgerufen und danach `layout()` was einen Button erzeugt mit dem man `login()` aufrufen kann. Aber das wurde dann ja schon explizit aufgerufen. Der Ablauf macht keinen Sinn.

So etwas wie `root` sollte nicht auf Modulebene existieren. Dort gehören nur Konstanten, Funktionen, und Klassen hin.

Hier ist auch wieder oder immer noch Geschäftslogik im GUI-Code enthalten. Aus dem GUI-Code heraus ruft man eine Methode auf dem hier nicht vorhandenen Anwendungsobjekt auf, oder zumindest eine entsprechende Funktion, die prüft ob übergebener Name und Passwort gültig sind. Man programmiert so etwas nicht inklusive Datenbankverbindung direkt in einer GUI-Klasse aus.
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

Danke BlackJack für deine Antwort.

Ich muss ehrlich zugeben, ich versteh nicht mal die hälfte von dem was du gerade geschrieben hast.

Punkt 1: Deswegen seh ich auch nix in der Konsole, das hab ich begriffen.
Punkt 2: Bahnhof, mehr kommt bei mir da nicht an
Punkt 3: Verstanden, wurde geändert und nun bleibt auch die Eingabe in den Feldern stehen
--> Fehler: Jetzt bekomm ich den Fehler das in der SQL-Abfrage die Attribute (benutzername und passwort) nicht definiert sind
Punkt 4: Hab sie nun ans ende des gesamten Codes gesetzt
Punkt 5: Versteh ich nicht ganz was du genau meinst, vermute mal das ich die Datenbankverbindung extra schreiben soll und nur bei bedarf einbinden soll
aber wie ruf ich Methoden (hoffe mal das ich gerade richtig liege) in einer anderen auf? Dahinter bin ich noch nicht ganz gestiegen
BlackJack

@Kalli87: Ich denke Du willst da viel zu viel auf einmal machen/lernen. Normalerweise implementiert man zuerst die Geschäftslogik eines Programms, also völlig ohne GUI. Und wenn das fertig und *getestet* ist, dann setzt man die GUI drauf. Dann ist auch alles schön sauber getrennt. Und wenn eine Datenbank beteiligt ist, dann entwirft man diese bevor man die Geschäftslogik implementiert. Du fängst mit der GUI an, also eigentlich von der falschen Seite. Manchmal fängt man mit einem GUI-Entwurf an um ein besseres Verständnis dafür zu bekommen welche Operationen die Geschäftslogik anbieten muss, aber die würde man dann trotzdem unabhängig von der GUI implementieren und testen und dann erst mit der GUI verbinden.
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

Du schreibst von "Geschäftslogik", was meinst du genau damit?
BlackJack

@Kalli87: Das Programm ohne die GUI. Der Teil der das tut was das Programm tun soll. Zum Beispiel Logindaten prüfen, Daten ermitteln, filtern, anlegen, und so weiter.
Astorek
User
Beiträge: 72
Registriert: Samstag 24. Januar 2009, 15:06
Kontaktdaten:

Ich bin mir ziemlich sicher, BlackJack spielt auf das Model-View-Controller-Entwurfsmuster an. Ich für meinen Teil könnte mir nicht vorstellen, OOP (noch dazu mit GUI) einigermaßen anständig und übersichtlich zu programmieren, wenn ich nicht auf dieses Muster gestoßen wäre^^.

Ich habe mir mal erlaubt, ein kleines Testprogramm in MVC-Manier zu schreiben, mit dem man meiner Meinung nach relativ gut sieht, wie die Objekte ineinandergreifen und über Events kommunizieren.
(Allerdings, gleich vorneweg gesagt: Ich habe keine Ahnung, ob das richtig konform mit "The Python Way" ist - zumindest für mich hat sich dieser Weg als relativ produktiv herausgestellt, aber ich vermute, dass ich von den "alten Hasen" hier im Forum wohl noch eins für den Code auf den Deckel bekommen werde^^).

http://pastebin.com/RQrLW6mZ

Wenn man sich die Klassen allein und für sich ansieht, erkennt man daraus die Vorteile:
  • Das Modell ist komplett vom Controller und Viewer unabhängig und teilt nur mit, wenn sich was im Modell geändert hat. Und mal das blödeste Schulbeispiel überhaupt zu bringen: Objekt "Auto" hat die Methode "Türen_Auf". Es ändert eine Variable, sendet ein Event aus, und macht sonst nix. Das Modell ist ganz sicher nicht dafür verantwortlich, wie es aussieht.
  • Der Viewer stellt "nur" die grafische Oberfläche dar und bietet Methoden an, um die Oberfläche zu manipulieren. Es muss sich nicht darum kümmern, was passiert, wenn z.B. ein Button gedrückt wird. Aber es teilt per Event mit, DASS ein Button gedrückt wurde.
  • Der Controller mimt quasi den "Übersetzer" zwischen Viewer und Modell. In meinem pastebin-Beispiel nimmt er auch die abgefeuerten Events vom Modell entgegen, es gibt aber ebenso die Möglichkeit, diese im Viewer zu verarbeiten (Genaueres erklärt der oben verlinkte Wikipedia-Artikel). Vorallem aber fängt er die Events des Views ab und verarbeitet sie dann weiter.
Hoffe, ich konnte helfen^^.
BlackJack

@Astorek: Also eigentlich wollte ich nur auf Trennung von GUI und Geschäftslogik hinaus. Die volle Trennung in MVC mache ich relativ selten. Nur dann wenn ich das tatsächlich *brauche*, weil's sonst einfach nur zusätzliche Komplexität ist.
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

Das is alles recht Komplex, in PHP is das alles nicht sooo krass komplex wie bei Python.
Deswegen sieht oder sah meine Struktur auch ganz anders als ihr es gewohnt seid.

Warum kann das nicht einfach einheitlich sein ^^
BlackJack

@Kalli87: Bei PHP würde das genau so aussehen wenn man damit Programme schreiben würde/müsste die vom Ablauf her nicht auf einen kurzen Anfrage/Antwort-Zyklus von einem Webserver beschränkt wären. Dort hast Du zumindest einen Teil von der Trennung von GUI und Geschäftslogik schon dadurch das die Benutzereingaben getrennt sind weil sie im Browser, also ausserhalb des PHP-Programms stattfinden.

Trotzdem kann man in PHP (zu) leicht GUI und Geschäftslogik mischen weil es dort so ”schön” einfach ist auch Code der nicht direkt mit der Anzeige zu tun hat mitten in HTML hinein zu schreiben.

Der Anfrage/Antwort-Zyklus hat auch Einfluss auf die Art und den Umfang wie man OOP verwendet, weil die Lebensdauer von allen Objekten doch sehr eingeschränkt ist. Und deswegen kann man das nicht einfach einheitlich machen, denn das ist bei Desktop-GUI-Anwendung halt anders, weshalb die auch anders strukturiert werden als Webanwendungen im PHP-Stil. Wie gesagt, auch in PHP könnte man da nicht so vorgehen. Kannst das ja mal ausprobieren, es gibt ja auch GUI-Toolkit-Anbindungen für PHP. :-)
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

NEEEEE :D
Niemals :D

Ich hab jetzt Feierabend und mein Hirn hat schon vor Stunden aufgegeben über diese Struktur nachzudenken.
Hab es eher mit lesen gequält und nu is Schicht im Schacht. :D

Ich wünsch euch was, ich verkrümle mich jetzt nach hause ^^
Benutzeravatar
/me
User
Beiträge: 3561
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

Kalli87 hat geschrieben:Das is alles recht Komplex, in PHP is das alles nicht sooo krass komplex wie bei Python.
Wenn man in PHP ordentliche Programme schreibt, dann wird man auch dort das MVC-Pattern einsetzen.

Vor 15 Jahren, als ich noch mit PHP programmiert habe, war das dort, zumindest jenseits der wilden Programmierung durch Anfänger, bereits üblich.
BlackJack

@Kalli87: Ich dachte ich schreibe mal eine kleine Login-GUI in PHP aber die Gtk-Anbindung scheint tot zu sein. Kein Paket über die Paketverwaltung von Ubuntu und die letzte ”Neuigkeit” auf der Homepage des Projekts ist von 2010. Die letzte Version wurde 2008 angekündigt. Naja, ist ja auch irgendwie verständlich — niemand der Wert auf seine geistige Gesundheit legt, schreibt Programme in PHP. :twisted:

Du solltest Dir jedenfalls zuerst mal Gedanken darüber machen was für Daten Du hast, wie die in Datenstrukturen zusammengefasst werden, und welche Operationen Du auf diesen Datenstrukturen benötigst. Das kann man dann implementieren und testen. Und dann kann man da eine GUI draufsetzen mit der sich die Daten anzeigen und über die Operationen manipulieren lassen.

Wir kennen bis jetzt nur das wahrscheinlich unwichtigste am Programm aus Programmierersicht, nämlich das man sich am Anfang anmelden muss. Wobei das bei einer lokalen Anwendung in Python zumindest aus sicherheitstechnischer nur Sinn macht wenn der Benutzer keine Rechte für den Zugriff auf das Programm hat, denn da müssen ja die Zugangsdaten zur Datenbank hinterlegt sein. Wenn der Benutzer da dran kommt, dann schützt eine Anmeldung im Programm nicht wirklich.

Die Daten die man dafür braucht sind Benutzername und Passwort vom Benutzer und der Hashwert zum Passwort von dem Benutzer aus der Datenbank, also braucht man für eine Funktion die die entscheidet ob ein Login erfolgreich ist die Eingaben vom Benutzer und eine Verbindung zur Datenbank. Die könnte man auch *in* der Funktion herstellen, aber so eine Verbindung möchte man in der Regel nicht für jede Anfrage erstellen, also erstellt man die üblicherweise am Anfang des Programms und benutzt die im Laufe des Programms für alle Anfragen, oder zumindest mehr als eine. Und an der Stelle kann man sich dann schon überlegen ob man mit einer Funktion arbeitet oder vielleicht besser ein Anwendungsobjekt erstellt das die Datenbankverbindung kapselt.
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

Hier mal eine auszug aus einem älteren Programm:

Code: Alles auswählen

<?php
class kalender
{
    private $monat;
    private $monatsnamen=array('Januar','Feburar','März','April','Mai','Juni','Juli','August','September','Oktober','November','Dezember');
    private $jahr;
    private $kal_datum;
    private $kal_tage_gesamt;
    private $kal_start_timestamp;
    private $kal_start_tag;
    private $kal_ende_tag;
     
     
    public function     __construct()
    {
         
            setlocale(LC_TIME, "de_DE@euro");          
                     
            if (isset($_GET['datum']))
                {
                    $this->kal_datum = $_GET['datum'];
                }
            else
                {
                    $this->kal_datum = time();
                }         
             
            $this->monat=date('m', $this->kal_datum);
            $this->jahr=date(' Y', $this->kal_datum);    
    }
     
    function            __toString()
        {
            $ret = "";
            $ret .=$this->format_datum();
            $ret .=new bilder($this->monat);
            $ret .="<a href='index.php?datum=".$this->monat_zurueck()."'>&laquo</a>";
            $ret .=$this->monatsnamen[$this->monat-1];           
            $ret .=$this->jahr;
            $ret .="<a href='index.php?datum=".$this->monat_vor()."'>&raquo</a>";
            $ret .=$this->format_datum();
            $ret .=$this->kalender_anzeigen();              
            return $ret;
        }
         
    private function navi()
    {
        $ret = "";
        return $ret;
    }
     
    private function format_datum()
    {
    $ret ="";
    setlocale(LC_TIME, "de_DE");
    //$this->kal_datum = time();
    $this->kal_tage_gesamt = date("t", $this->kal_datum);
    $this->kal_start_timestamp = mktime(0,0,0,date("n",$this->kal_datum),1,date("Y",$this->kal_datum));
    $this->kal_start_tag = date("N", $this->kal_start_timestamp);
    $this->kal_ende_tag = date("N", mktime(0,0,0,date("n",$this->kal_datum),$this->kal_tage_gesamt,date("Y",$this->kal_datum)));
    $this->ret .= utf8_decode (strftime("%B %Y", $this->kal_datum));
    return $ret;
    }
     
    private function kalender_anzeigen()
    {
        $ret ="";
        $this->format_datum();
        #$this->kal_tage_gesamt = date("t", $this->kal_datum);
        $ret .='  
            <table border="1">
            <thead>
            <tr>
                <th>Mo</th>
                <th>Di</th>
                <th>Mi</th>
                <th>Do</th>
                <th>Fr</th>
                <th>Sa</th>
                <th>So</th>
            </tr>
            </thead>';
         
        $ret .= "<tbody>";
                for($i = 1; $i <= $this->kal_tage_gesamt+($this->kal_start_tag-1)+(7-$this->kal_ende_tag); $i++)
                {
                    $this->kal_anzeige_akt_tag = $i - $this->kal_start_tag;
                    $this->kal_anzeige_heute_timestamp = strtotime($this->kal_anzeige_akt_tag." day", $this->kal_start_timestamp);
                    $this->kal_anzeige_heute_tag = date("j", $this->kal_anzeige_heute_timestamp);
                    if(date("N",$this->kal_anzeige_heute_timestamp) == 1)
                    $ret .= "<tr>";
                    if(date("dmY") == date("dmY", $this->kal_anzeige_heute_timestamp))
                    $ret .= '<td class="kal_aktueller_tag">'.$this->kal_anzeige_heute_tag.'</td>';
                    elseif($this->kal_anzeige_akt_tag >= 0 AND $this->kal_anzeige_akt_tag < $this->kal_tage_gesamt)
                    $ret .= '<td class="kal_standard_tag">'.$this->kal_anzeige_heute_tag.'</td>';
                    else
                    $ret .= '<td class="kal_vormonat_tag">'.$this->kal_anzeige_heute_tag.'</td>';
                    if(date("N",$this->kal_anzeige_heute_timestamp) == 7)
                    $ret .= "</tr>";
                }      
        $ret .= "</table>";
        return $ret;
    }
 
    private function monat_vor()
    {
        $vor = mktime(0,0,0,date("n",$this->kal_datum)+1,1,date("Y",$this->kal_datum));
        return $vor;
    }
     
    private function monat_zurueck()
        {
            $zurueck = mktime(0,0,0,date("n",$this->kal_datum)-1,date("d",$this->kal_datum),date("Y",$this->kal_datum));
            return $zurueck;
        }   
}
?>
Wie man daraus erkennen kann handelt es sich dabei um ein Kalender ;)
Die zweite Datei hab ich mal weggelassen da diese nur für die Bilder zuständig war.

Was ich damit sagen will ist das ich bereits mit OOP konfrontiert wurde und in PHP
komm ich besser klar als in Python. Liegt vllt auch daran das ich ein Jahr intensiv zugebombt
wurde was PHP betrifft und dementsprechend auch OOP. Ihr schreibt auch recht von oft MVC
mir sind da eher die UML Diagramme ein Begriff die mir ebenso ins Hirn gehämmert wurden.
Sirius3
User
Beiträge: 18264
Registriert: Sonntag 21. Oktober 2012, 17:20

@Kalli87: da fällt mir ein, dass ich in PHP noch nie Klassen gebraucht habe. Wahrscheinlich, weil ich komplexere Dinge lieber in Perl geschrieben habe. Dein Beispiel ist auch ein schönes Exempel, dass man eigentlich keine Klasse dafür braucht. Das einzige, was die Klasse macht ist, die Funktion "__toString" bereitzustellen. Dafür braucht man keine Klasse, da reicht die Funktion völlig aus.
Zudem ist die Klasse nicht sinnvoll einsetzbar. Der Konstruktor benutzt $_GET und ändert zudem noch die Locale LC_TIME, ein globaler Zustand. Man ist also auf Deutsches Datum festgelegt. Es wird vorausgesetzt, dass die Seite 'index.php' heißt. Das ganze Template ist auch tief im Code verwoben.
format_datum ist eine seltsame Funktion. Sie liefert immer einen leeren String zurück, der noch an zwei Stellen ins Ergebnis eingebaut wird, formatiert also kein Datum.
Wenn das ein Beispiel für OOP sein soll, verstehe ich, dass Dir das bei Python so anders vorkommt.
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

@Sirius3
Jetzt mach mein Beispiel nicht runter :D
ja die "__tostring" funktion wurde später mal in asugelagert in eine "Bibliothek" die
eingebunden wurde. Die index.php is Standard, ich könnte ja noch mein
"WebShop" als Beispiel posten was ebenso in PHP geschrieben wurde. Aber das is bissl
in die Hose gegangen damals. Der Kalender selbst wurde ja mit Hilfe des Lehrers umgesetzt
was halt nach deren Anleitung ging. :P

Denke mal mein Problem liegt einfach darin das ich das Verständnis in Python für OOP nicht ganz habe
und deswegen Probleme habe es umzusetzen. Es gibt halt auch keinen "construtor" und was mich immer
total verwirrt is dieses "self" und mir fehlt das gute alte "$"-Zeichen :D
BlackJack

@Kalli87: Nach welchem Material lernst Du OOP in Python? Was denkst Du was `__init__()` ist? Wie kann Dich `self` verwirren, `this` aber offenbar nicht‽ Und was soll das $ vor Namen bringen? Denn das müsste man in Python tatsächlich vor *jeden* Namen schreiben und wenn man etwas *überall* davor schreiben muss, dann hat das keinen Informationswert und man kann es auch einfach weg lassen.

Ich habe ja so ein bisschen das Gefühl Du hast auch OOP in PHP nicht verstanden und/oder Dich noch überhaupt nicht ernsthaft in Python damit auseinandergesetzt.
Kalli87
User
Beiträge: 281
Registriert: Montag 10. November 2014, 11:27

http://www.python-kurs.eu/python3_klassen.php
http://www.tutorialspoint.com/python/py ... bjects.htm

"Einstieg in Python" und "Python 3" als Buch

"__init__()" ist kein wirklicher "constructor" lediglich, wie der name schon sagt, initialisiert es etwas. So hab ichs
bis jetzt gelernt bzw erlesen. In meinem Kopf hängt halt das ganze von PHP noch fest deswegen fällt es mir so
schwer mich der Materie in Python rein zu versetzen.
Das hab ich aber auch schon geschrieben.

Und aus "Einstieg in Python" is halt nur dieses blöde Beispiel mit den Autos drinnen(beschleunigen, bremsen, Farbe, Marke......)
Ich hab mir sogar schon auf YouTube einige Videos dazu angeschaut und trotzdem werd ich nur langsam schlau daraus.
Es braucht halt zeit.......

Mittlerweile wird's ja schon besser mit dem ganzen OOP
BlackJack

@Kalli87: Die Unterschiede zwischen `__init__()` und `__construct()` sind minimal, denn auch in PHP wird da nur das bereits bestehende Objekt initialisiert. Du erzeugst das Objekt dort ja nicht, sondern weist lediglich Attributen einen Wert zu. Der einzige Unterschied ist, dass man die Attribute in PHP deklarieren muss und in `__construct()` nicht initialisieren *muss*. Das sind jetzt aber keine wirklich gravierenden Unterschiede was das Verständnis von OOP angeht.
Benutzeravatar
/me
User
Beiträge: 3561
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

Kalli87 hat geschrieben:"__init__()" ist kein wirklicher "constructor" lediglich, wie der name schon sagt, initialisiert es etwas.
Was möchtest du von einem "wirklichen" Konstruktor haben, was __init__ nicht kann?

Der eigentliche Konstruktor heißt übrigens __new__ und die meisten Entwickler benötigen ihn quasi überhaupt nicht.
Antworten