Python 3.5 ist raus...

[Sirius3]

... sondern im Sinne von bestimmten Eigenschaften

Und dort fängt der Punkt an, wo ich befürchte, dass 90% der Bibliotheksentwickler und 99.99% der Dozenten konkrete Typen statt Eigenschaften zur Annotation nehmen. Wenn irgendwo float als Typ steht, ich aber nicht weiß, ob auch all die anderen numerischen Typen erlaubt sind, dann richtet diese Art der "Dokumentation" meiner Meinung nach mehr Schaden an, als sie nützt. Und ich wage mal zu wetten, dass es kein allgemeines Python-Lehrbuch gibt (außer die Dokumentation der ABC-Klassen) gibt, das sich mit ABC-Klassen beschäftigt.

[DasIch]

Der Typing Kram kommt doch gar nicht mit neuer Syntax, er nutzt nur die bisherige Syntax von Annotations die es schon seit 3.0 gibt. Außerdem werden Typ Annotationen vom Interpreter ignoriert. Python 3.5 kommt noch nicht einmal mit einem eigenen Tool um diese zu überprüfen. Wenn es ein Problem damit gibt dann ist es mangelndes Tooling.

Was die async Syntax angeht, ist die ja in bester Python Tradition von anderen Sprachen kopiert, in denen sie sich bewährt hat. Die Syntax erlaubt auch nur dass zu tun was man bisher sowieso schon z.B. mit Deferreds in Twisted bisher umständlicher mit einer API gemacht hat.

[BlackJack]

@cofi: Die Annahmen über das Verhalten von Argumenten und Rückgabewerten kann man auch ganz prima mit Docstrings dokumentieren, dafür sind sie ja da.

Studenten werden lernen das da konkrete Typen reingehören, weil es das ist was Dozenten toll finden. Entwickler werden dort eher konkrete Typen verwenden weil das ad hoc einfacher ist genau den Typ reinzuschreiben den man beim schreiben im Hinterkopf hatte, statt sich da lange/länger Gedanken machen zu müssen *oder* sie werden sich hellauf begeistert *viele* Gedanken machen und eine möglichst facettenreiche ABC-Hierarchie ausdenken bei der jeder Teilaspekt eines Protokolls in einem eigenen ABC steckt und die dann wieder per Mehrfachvererbung zu Gesamttypen zusammengefasst werden. So wie das bei `io` ja schon passiert ist. Voher gab's `file`, nun gibt's Typen für lesbare Dateien, schreibbare Dateien, Textdateien, Binärdateien, ”rohe” Dateien, gepufferte Dateien, …; Jaaaaavaaaaa \o/

@DasIch: Noch werden die Typinformationen ignoriert. Das ist nur eine Studienarbeit o.ä. entfernt das sich das ändert, also mindestens für Studenten. Dann fehlt noch das jemand etwas schreibt das Python-Code mit Typannotationen schneller macht — sehr wahrscheinlich je konkreter die Typen, um so leichter kann man Sachen beschleunigen. Und schon haben wir optionale statische Typisierung statt einfach nur das harmlos klingende ”Annotationen”. Dann haben wir die ganzen Nörgler das Python ja so langsam sei und die Studis die die Sprache mit statischer Typisierung lernen, und schon haben gibt es eine Fraktion die das ganze nicht mehr so optional sieht. Das nächste wird dann Syntax um lokale Namen zu typisieren, pardon annotieren meinte ich natürlich. Ich mag Python 2.7 eigentlich ganz gerne.

[DasIch]

Ich steh den Typ Annotationen jetzt nicht unbedingt positiv gegenüber aber ich glaub so schlimm wirds nicht werden. Sicherlich werden einige Leute die in fragwürdiger oder einfach nur schlechter Art und Weise benutzen aber auch schon ohne Typ Annotationen werden regelmäßig schwerste Verbrechen gegen Lesbarkeit und gutes API Design begangen, wahrscheinlich schon im nächsten neuen Thread einen Tab weiter. Typ Annotationen machen die Situation nicht besser und geben sicherlich mehr Spielraum um da kreativ zu werden aber davon sollte man sich im Sprachdesign nicht allzu sehr einschränken lassen.

Ich bezweifle auch stark dass wir irgendwelche Optimierungen darauf basierend in absehbarer Zeit sehen werden. In CPython werden sie definitiv nicht passieren und die PyPy Leute sind der Meinung dass sie mit den Typ Annotationen nichts anfangen können. Es müsste also schon noch jemand anders einen Interpreter bauen der mit CPython und PyPy konkurrieren kann.

[BlackJack]

@DasIch: Ich denke man sollte beim Sprachentwurf auch das Missbrauchspotential von Features berücksichtigen. Oder überhaupt mal über den Sinn von Features nachdenken. Erst waren es nur Annotationen mit denen man irgendwas beliebiges anstellen konnte, beispielweise Typannotation. Was dann ewig niemand gemacht hat. Nun gibt es speziell für die Verwendung als Typannotation Unterstützung in der Standardbibliothek. Wobei halt auch nur für die Annotation. Konkrete Verwendung Fehlanzeige. Wozu ist das denn gerade nützlich? Wirklich nur zu Dokumentationszwecken um sich ein Format und einen Parser für Doctstrings zu sparen? Was bis jetzt zumindest aber auch noch nicht benutzt wird. Wobei es da ja schon eine Alternative mit Docstrings gibt die das seit Jahren kann, und vor Sphinx gab's Epydoc was noch länger zurück geht.

Ich sehe da irgendwie wenig Sinn, dafür aber die schon erwähnten Gefahren. Was soll dieses Feature das es schon über 6 Jahre gibt, das aber nicht benutzt wird? Oder gab's da bisher schon irgendeinen sinnvollen Einsatz für?

[snafu]

`format()` wird in Python 3.6 dahingehend weiterentwickelt bzw. ersetzt durch f-Strings mit Werteinterpolation, also beispielsweise: greeting = f'My name is {name} and I am {years} years old, because I was born {birthday:%d.%m.%Y}'

Hier übrigens das zugehörige PEP für alle, die noch nicht drauf gestoßen sind:

https://www.python.org/dev/peps/pep-0498/

[/me]

Hier übrigens das zugehörige PEP für alle, die noch nicht drauf gestoßen sind:

https://www.python.org/dev/peps/pep-0498/

Den PEP hätte ich nicht am 1. August, sondern am 1. April erwartet.

[snafu]

Vielleicht möchte Python ja am Ende zu einem skurrilem Sketch werden, ganz wie das große Vorbild.

Möglicherweise wird Python auch heimlich von PHP-Entwicklern unterwandert. Wer weiß...

[Sr4l]

Bei sowas denke ich sofort an exec.

Code: Alles auswählen

>>> f'{{ {4*10} }}'
'{ 40 }'
>>> f'{{{4*10}}}'
'{40}'
f"abc {a['x']} def"

Und wenn man sich da schon dachte OMG. Dann geht es erst richtig los:

>>> def foo():
... return 20
...
>>> f'result={foo()}'
'result=20'

Is equivalent to:

Code: Alles auswählen

>>> 'result=' + str(foo())
'result=20'

[BlackJack]

@Sr4l: Naja immerhin kann man die nicht als Benutzereingabe ins Programm schleusen und die werden ja auch nicht so ausgeführt sondern vom Compiler in Bytecode für äquivalenten Code ohne f-Strings umgesetzt.

Ich musste lächeln an der Stelle im PEP wo die Kombination von 'f' und 'u' kombiniert als Präfix ausgeschlossen wird. Also keine „f*ck you“-Strings.

[snafu]

Ich finde, Python wird inzwischen mit jeder neuen Version austauschbarer und langweiliger. Es gibt wenig eigenständiges, sondern man will nur noch so sein wie die anderen populären Sprachen. Früher hatte man noch Konzepte aus anderen Sprachen als Inspiration für eine Eigenkreation genutzt - sozusagen mit eigenen Akzenten. Aber seit ein paar Jahren wirken viele Neuerungen auf mich nur noch wie in Python übernommene 1-zu-1-Abbilder. Und wo früher mal Python als Vorbild für manch andere Sprache galt, ist es heutzutage wohl eher umgekehrt.