Hallo Zusammen,
ich will ein neues str Class erstellen, dabei soll es ein Slot für str Buffer aus Master Class verwenden.
z.B.: wenn ich ein List Class erstelle:
class MyList(list):
def __init__(self, iterable: iter):
super(MyList, self).__init__()
self.set(iterable)
def set(self, iterable: iter) -> 'GList':
super().__init__(iterable)
return self
t = MyList([1, 2, 3])
print(t) -> [1, 2, 3]
t.set([20, 30, 50])
print(t) -> [20, 30, 50]
Dann funktioniert es super, weil Masterclass list nutzt sein Slot in funktion list.__init__(), aber Masterclass str nutzt sein Slot in funktion str.__new__(), dass bedeutet, es aktualisiert nicht aktive Class, sondern es macht Return des neuen Classes.
mein Bsp. für str Class:
class MyStr(str):
def __new__(cls, *args, **kwargs):
self = super(GStr, cls).__new__(cls, args[0])
return self
def __init__(self, value):
super(MyStr, self).__init__()
self.set(value)
def set(self, value):
# was soll ich hier chreiben?
p = MyStr("Start")
print(p) -> "Start"
p.set("Change")
print(p) -> "Start", aber muss "Change" sein
class MyStr(str):
- __blackjack__
- User
- Beiträge: 13123
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@zZanozZa: Zeichenketten sind unveränderlich. Das kann man durch Vererbung natürlich nicht ändern, denn dazu müsste die abgeleitete Klasse die Zeichenkette verändern können, aber `str` bietet keine Operationen dafür.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
@zZanozZa: Vererbung wird in Python selten verwendet, weil generell Vererbung ein schwieriges Thema ist. Man muß dafür sorgen, dass wirklich jede Methode sich konsistent verhält, bei Deiner MyList wird zum Beispiel beim `slicen` wieder ein Objekt vom Typ `list` zurückgeliefert.
Statt Vererbung verwendet man deshalb überall, wo es sinnvoll ist, Komposition.
Was ist Dein eigentliches Problem, das Du denkst, mit Vererbung lösen zu müssen?
Statt Vererbung verwendet man deshalb überall, wo es sinnvoll ist, Komposition.
Was ist Dein eigentliches Problem, das Du denkst, mit Vererbung lösen zu müssen?
- __blackjack__
- User
- Beiträge: 13123
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@zZanozZa: Ergänzend: Du verwendest `super()` falsch. Das man da Argumente übergeben muss war mal in Python 2. Im besten Fall ist das einfach nur überflüssig, im Fall von `MyStr` ist es falsch da dann `GStr` als erstes Argument zu übergeben.
Was verwendest Du denn um Typannotationen zu prüfen? Falls Du die nicht aktiv überprüfst, solltest Du auch keine Typannotationen machen, denn Fehler an der Stelle sind schlimmer als falsche Kommentare, weil der Leser sich darauf verlässt, dass die korrekt sind. `iter()` ist kein Typ sondern eine Funktion und die kann man so nicht als Typannotation verwenden.
Ich würde es auch als Fehler ansehen `__init__()` mehrfach aufzurufen. Es ist im allgemeinen nicht garantiert, dass man das mehr als einmal machen kann, das kann also funktionieren, muss es aber nicht. Man weiss nicht wie `list.__init__()` implementiert ist, da gibt es keine garantien. Es ist auf der anderen Seite aber einfach `clear()` und `extend()` zu verwenden und diese Unwägbarkeit so zu umgehen.
Methoden die ein Objekt verändern, geben das Objekt in Python in aller Regel nicht zurück. Guido hat sich bei den eingebauten Typen explizit dazu entschieden das *nicht* zu machen. Das wird also von den meisten als „unpythonisch“ angesehen.
Was verwendest Du denn um Typannotationen zu prüfen? Falls Du die nicht aktiv überprüfst, solltest Du auch keine Typannotationen machen, denn Fehler an der Stelle sind schlimmer als falsche Kommentare, weil der Leser sich darauf verlässt, dass die korrekt sind. `iter()` ist kein Typ sondern eine Funktion und die kann man so nicht als Typannotation verwenden.
Ich würde es auch als Fehler ansehen `__init__()` mehrfach aufzurufen. Es ist im allgemeinen nicht garantiert, dass man das mehr als einmal machen kann, das kann also funktionieren, muss es aber nicht. Man weiss nicht wie `list.__init__()` implementiert ist, da gibt es keine garantien. Es ist auf der anderen Seite aber einfach `clear()` und `extend()` zu verwenden und diese Unwägbarkeit so zu umgehen.
Methoden die ein Objekt verändern, geben das Objekt in Python in aller Regel nicht zurück. Guido hat sich bei den eingebauten Typen explizit dazu entschieden das *nicht* zu machen. Das wird also von den meisten als „unpythonisch“ angesehen.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Wenn Du lokal die Variable `self` änderst, hat das keinen Einfluß auf irgendeine Variable `p` in irgendeinem anderen Namensraum.
Deshalb nochmal die Frage: was willst Du eigentlich erreichen?
Bisher hast Du nur Lösungen gezeigt, die nicht funktionieren.
Also mußt Du zwei, drei Schritte zurückgeben und mal ganz von vorne erzählen, was Deine Aufgabe ist?
Deshalb nochmal die Frage: was willst Du eigentlich erreichen?
Bisher hast Du nur Lösungen gezeigt, die nicht funktionieren.
Also mußt Du zwei, drei Schritte zurückgeben und mal ganz von vorne erzählen, was Deine Aufgabe ist?