Generics should be specified through square brackets

[mechanicalStore]

Folgendes Beispiel funktioniert, aber der Editor meckert mit der Meldung im Subjekt:

Code: Alles auswählen

from pprint import pprint

class A:
    def __init__(self):
        self.id: int = 50
        self.Ps: list(P) = []       # <------

class P:
    def __init__(self, pa_id: int):
        self.pa_id = pa_id

def main():
    pa = A()
    pm = P(pa.id)
    pa.Ps.append(pm)
    pprint(vars(pa))
    pprint(vars(pm))

if __name__ == '__main__':
    main()

Aber

Code: Alles auswählen

self.Ps: P[] = []

erzeugt Expression expected. Stehe auf dem Schlauch. Und zweitens; ist das wechselseitige referenzieren (also id aus A in P und P in Ps Liste von A) ein Problem?

Danke und Gruß

[__blackjack__]

@mechanicalStore: Wo hast Du denn nachgeschaut wie man diese Typannotation macht? Wie bist Du auf die runden Klammern gekommen? Und warum änderst Du dann nicht nur *das*, denn nur *die* sind ja falsch. Stattdessen lässt Du einen Typ weg und schreibst den anderen woanders hin. Programmieren durch raten funktioniert nicht wirklich.

Die `int`-Annotation beim `id`-Attribut gehört da nicht hin. Jeder menschliche Leser sieht das 50 eine ganze Zahl ist, und auch die Werkzeuge zur Typprüfung sehen das problemlos. Für Annotationen gilt das gleiche wie für Kommentare: wenn sie dem Leser keinen Mehrwert über den Code bieten, gehören sie da nicht hin.

Welches Problem entsteht denn durch den Code beim Ausführen? Welche würdest Du da erwarten?

[mechanicalStore]

Stattdessen lässt Du einen Typ weg und schreibst den anderen woanders hin. Programmieren durch raten funktioniert nicht wirklich.

Da war ich gedanklich wohl ganz woanders... Bin jetzt hier https://docs.python.org/3/library/stdty ... lias-union fündig geworden. Hatte dazu bisher keinen Anwendungsfall.

Die `int`-Annotation beim `id`-Attribut gehört da nicht hin. Jeder menschliche Leser sieht das 50 eine ganze Zahl ist, und auch die Werkzeuge zur Typprüfung sehen das problemlos. Für Annotationen gilt das gleiche wie für Kommentare: wenn sie dem Leser keinen Mehrwert über den Code bieten, gehören sie da nicht hin.

Dagegen könnte man argumentieren, dass auch float, str, etc. erkennbar sind. Trotzdem findet man diese Annotationen in vielen Beispielcodes.

Welches Problem entsteht denn durch den Code beim Ausführen? Welche würdest Du da erwarten?

Er läuft auch mit (den ja falschen) runden Klammern einwandfrei durch. Und das ist dann nicht verständlich.

Danke für Deine Erklärungen.

[grubenfox]

Für das bzw. beim Ausführen vom Code werden diese ganzen Annotationen komplett ignoriert, daher ist das sehr verständlich.

[__blackjack__]

@mechanicalStore: Jo man findet viele schlechte Beispielcodes, denn natürlich ist das bei ``float`` auch Unsinnig wenn man da einen literalen Gleitkommawert zuweist, noch mal ``float`` zu annotieren. Das gilt insbesondere für literale Werte die eindeutig sind, aber auch auch für beliebige Datentypen wo der Datentyp aufgerufen und das Ergebnis zugewiesen wird.

Code: Alles auswählen

origin: Point = Point(23, 24)

# bietet absolut keinen Mehrwert über

origin = Point(23, 42)

Wer beim zweiten nicht sieht, dass der `origin`-Wert vom Typ `Point` ist, dem wird auch die Annotation nicht helfen. Und wie gesagt gilt das sowohl für Menschen wie auch für die Werkzeuge mit denen man diese Annotation überprüft.

Ich finde das ein bisschen ironisch, dass man diesen Unsinn bei Java mit dem ``auto``-Schlüsselwort nach Ewigkeiten endlich losgeworden ist, und jetzt Leute bei Python mit dem Unsinn anfangen.

Code: Alles auswählen

// Java früher:
Point origin = new Point(23, 42);

// Heute:
auto origin = new Point(23, 42);

Das die Annotationen genau Null Einfluss auf den Programmablauf haben, wie grubenfox ja schon schrieb, hat übrigens auch zur Folge, dass es wirklich wichtig ist, dass man Annotationen selber mit einem entsprechenden Werkzeug überprüft, damit man da nix Falsches hin schreibt. Denn genau wie bei Kommentaren sind inhaltlich falsche Annotation schlimmer als keine Annotationen. Letztlich sind Annotationen Kommentare denen der Leser mehr vertrauen schenkt als normalen Kommentaren, denn im Gegensatz zu normalen Kommentaren sind Annotation formal definiert und automatisch überprüfbar, und man geht als Leser davon aus, dass das auch passiert, die also inhaltlich korrekt sind, weil es keinen vernünftigen Grund gibt, das sie es nicht sind.