Syntax Übersicht

[Axel58]

Guten Morgen,

ich suche eine einfache Liste der Befehls Syntax. Da ich 30 Jahre Programmierer war, ist mir schon klar, was ich tun will, aber da ich mit Python gerade angefangen habe, wie mach ich es?
Zum Beispiel
def fkt(p1,p2) -> Klasse

Wofür steht der Zusatz ->Klasse?

Ich hab schon länger im Internet gesucht , aber nix passendes gefunden.

Vielen Dank für Eure Vorschläge!

[pillmuncher]

Das bedeutet, dass fkt die zwei Aurgumente p1 und p2 erwartet und ein Objekt vom Typ Klasse als Ergebnis zurückliefert. Das Konstrukt "-> T" ist eine Typ-Annotation, die keinerlei Einfluss auf das Programm hat. Sowas benutzt man zur Dokumentation oder wenn man ein externes Programm zur Typ-Prüfung drüberlaufen lässt, etwa mypy.

[__blackjack__]

@Axel58: Nicht irgendwo im Internet suchen, sondern in der Dokumentation. Wenn man dort "->" in die Suche eingibt, kommt man zu zwei Suchtreffern: dem Abschnitt „Function Annotations“ im Tutorial, und der entsprechenden Stelle im Abschnitt „Function definitions“ in der Sprachreferenz.

Das Tutorial in der Python-Dokumentation sollte man mal durchgearbeitet haben.

Eine einfache Liste der Befehlssyntax geht nicht mehr wirklich. Die Sprache ist mittlerweile ganz schön komplex geworden.

[DeaD_EyE]

Sowas benutzt man zur Dokumentation oder wenn man ein externes Programm zur Typ-Prüfung drüberlaufen lässt, etwa mypy.

Mich wachsender Größe des Programms kann das sinnvoll sein, vor allem dann, wenn es über mehrere Module verteilt ist.
Wenn man es falsch einsetzt, kann es sogar kontraproduktiv sein und zu falschen Annahmen führen.

Anfängern würde ich auch erstmal davon abraten. TypeHints sind eine Wissenschaft für sich.

Für jede Sprache gibt es Cheat-Sheets: https://www.google.com/search?q=python+cheat+sheet

Erster Treffer: https://www.pythoncheatsheet.org/

Definition des Syntax von Python: https://docs.python.org/3/reference/index.html

[__blackjack__]

Typ-Annotationen haben mich gerade wieder total ”begeistert” als das an einer Zeile wie ``answer: Number = 42`` gescheitert ist, weil 42 keinen passenden Typ für `numbers.Number` hat. Und wie lange das bekannt ist. Und wie schlecht das in der Dokumentation kommuniziert wird, dass der `numbers`-Stack sich nicht für Typ-Annotationen eignet. Und das jeder der darüber stolpert sich seine eigenen Notlösungen bastelt. Oder an der Stelle aufgibt das sinnvoll, nicht unnötig einschränkend zu annotieren.

[Axel58]

Moin, Moin

erst mal vielen Dank für Eure Hinweise,.

Die Python.org Site ist mir glatt durch die Lappen gegangen, aber das ist die Informationsquelle, die ich gesucht habe

[DeaD_EyE]

Typ-Annotationen haben mich gerade wieder total ”begeistert” als das an einer Zeile wie ``answer: Number = 42`` gescheitert ist, weil 42 keinen
passenden Typ für `numbers.Number` hat.

Ich hätte einfach int verwendet, wenn ein int erwartet wird. Falls man numbers.Number nutzt, wirft mypy folgende Fehlermeldung:

x.py:10: error: Argument 1 to "foo" has incompatible type "int"; expected "Number" [arg-type]
x.py:10: note: Types from "numbers" aren't supported for static type checking
x.py:10: note: See https://peps.python.org/pep-0484/#the-numeric-tower
x.py:10: note: Consider using a protocol instead, such as typing.SupportsFloat
Found 1 error in 1 file (checked 1 source file)

Code geändert und dann kommt die Fehlermeldung nicht mehr.
Ich bin schon so oft über TypeHints gestolpert, dass es mich wundert, wenn mal keine Fehlermeldung kommt.

Die Python.org Site ist mir glatt durch die Lappen gegangen, aber das ist die Informationsquelle, die ich gesucht habe

Ich habe die gesammte Doku bestimmt 3 mal durchgelesen. Wenn man am Flughafen im Transit festhängt, hat man Zeit ohne Ende. Vorteilhaft ist auch, dass man lernt mit der Dokumentation umzugehen. Pros können die Links aus dem Kopf im Browser richtig eingeben.

Test: https://docs.python.org/3/library/os.html

[__blackjack__]

@DeaD_EyE: Es wird ja kein `int` erwartet, dann hätte ich das ja *gar nicht* annotieren müssen, weil ich und `mypy` bei 42 `int` auch schon so annehmen. Es sollt halt mit Zahlen allgemein funktionieren, weil die Implementierung das tut.

`SupportsFloat` ist kein Typ sondern ein Protokoll. Das einzige was Objekte dafür erfüllen müssen, ist eine `__float__()`-Methode implementieren. Das war es dann auch schon. Demnach sind Werte vom Typ `complex` hier nicht möglich. Eine `__float__()`-Methode sagt aber nicht, dass man eine Zahl vor sich hat, sondern etwas, dass sich in eine (Gleitkomma)Zahl umwandeln lässt. Klar trifft das auf die meisten Typen zu die Zahlen implementieren, aber das kann auch auf andere Typen zutreffen die sich so überhaupt nicht wie Zahlen verhalten müssen, aber halt eine Methode haben um sie in eine Zahl umwandeln zu können.

Das ``issubclass(int, Number)`` und ``isinstance(42, Number)`` wahr sind, aber ``answer: Number = 42`` nicht von einem Typchecker akzeptiert wird, ist eine ziemlich bekloppte Situation. Vor 7 Jahren wurde das als Issue bei mypy eröffnet. Letztes Jahr wurde dann die Meldung eingebaut, und das Issue damit als erledigt geschlossen. Wer das irgendwie braucht soll sich doch bitte selber ein passendes Protokoll definieren und dagegen testen.

[Sirius3]

Numba erzeugt statisch typisierten Code ganz ohne Typannotation. Und C++ hat mit Templates dynamische Typisierung und per auto findet der Compiler in den meisten Fällen den Typ selbst raus.
Aber Pythonprogrammierer sollten Typen selbst festlegen, machen es in den meisten Fällen falsch, so dass ein dummer Typechecker ungerechtfertigte Fehlermeldung wirft, und man die meiste Zeit damit verbringen muss, work-arounds zu schaffen.
Statt also Zeit in Typannotation zu stecken, wäre es besser, diese in einen intelligenteren Typechecker zu investieren.