Seite 1 von 1

Syntax Übersicht

Verfasst: Sonntag 26. Mai 2024, 06:55
von 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!

Re: Syntax Übersicht

Verfasst: Sonntag 26. Mai 2024, 17:39
von 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.

Re: Syntax Übersicht

Verfasst: Sonntag 26. Mai 2024, 18:09
von __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.

Re: Syntax Übersicht

Verfasst: Mittwoch 29. Mai 2024, 22:06
von DeaD_EyE
pillmuncher hat geschrieben: Sonntag 26. Mai 2024, 17:39 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

Re: Syntax Übersicht

Verfasst: Donnerstag 30. Mai 2024, 12:08
von __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.

Re: Syntax Übersicht

Verfasst: Donnerstag 30. Mai 2024, 17:27
von 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

Re: Syntax Übersicht

Verfasst: Donnerstag 30. Mai 2024, 22:11
von DeaD_EyE
__blackjack__ hat geschrieben: Donnerstag 30. Mai 2024, 12:08 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.


Axel58 hat geschrieben: Donnerstag 30. Mai 2024, 17:27 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

Re: Syntax Übersicht

Verfasst: Donnerstag 30. Mai 2024, 22:58
von __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.

Re: Syntax Übersicht

Verfasst: Freitag 31. Mai 2024, 07:32
von 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.