Python 3.5 ist raus...

[jens]

http://www.heise.de/newsticker/meldung/ ... 11997.html

https://docs.python.org/3.5/whatsnew/3.5.html


Meinungen dazu?

[BlackJack]

@jens: Eine weitere 3.x, also eine weitere Version mit der ich nix anfangen kann.

[jens]

Ja, deine Meinung kenne ich ja

Aber machst du nie komplett neue Projekte?

[BlackJack]

@jens: Doch, aber die müssen halt am Ende auch in Python 2.x-Umgebungen laufen.

[Sr4l]

Mit Python 3.5 kann man endlich Code schreiben bei dem sich Coder die vll bei Python 2.6 aufgehört haben fragen könnten "Was ist das für eine neue Sprache?". Ich meine damit natürlich die neuen Schlüsselwörter async und await und 'PEP 484 - Type Hints'. Besonders die Type Hints lassen ganz schön seltsame Zeilen entstehen.

Code: Alles auswählen

def retry(url: Url, retry_count: int) -> None:
    pass

Code: Alles auswählen

from typing import TypeVar, Iterable, Tuple

T = TypeVar('T', int, float, complex)
Vector = Iterable[Tuple[T, T]]

def inproduct(v: Vector) -> T:
    return sum(x*y for x, y in v)

Es wird aber alles halb so schlimm sein. Ich finde es traurig immer noch bei Python2 zu hängen, ich hoffe das ändert sich bald.

[Sirius3]

Mit den Type-Annotations hat sich Python 3 für mich wieder ein Stück weiter disqualifiziert, wenn jetzt alle Welt anfängt, Bibliotheken mit strikten Typ-Überprüfungen zu schreiben. Bei der async-Syntax bin ich mir noch nicht sicher, ob das wirklich der Weg ist, den man gehen sollte, oder ob das nur so ein Hype ist, der in 5 Jahren wieder sang- und klanglos in der Versenkung verschwindet.
Einzig die Unpackingmöglichkeiten hätten schon viel früher umgesetzt werden sollen, weil sie wirklich manchen Code viel lesbarer machen. Wann gibt's den Backport .

[MagBen]

Der neue Operator @ für Matrizenmultiplikation könnte ein Argument für Python 3 sein (z.B. in einer Vorlesung für Lineare Algebra). Wobei mir

Code: Alles auswählen

b = A ° x

besser gefallen hätte als

Code: Alles auswählen

b = A @ x

Eigentlich ist es ja ein Tensorprodukt, da es wohl mit beliebigen Dimensionen funktionieren wird.

Das asynchrone Zeug ist ja ganz nett, aber in der GUI-Programmierung wohl nicht brauchbar. Jede GUI-Bibliothek hat da ja schon etwas Eigenes, das würde ich damit nicht mischen wollen. Problematisch finde ich auch, dass die Asynchronität zusammen mit der Funktion definiert wird, der Aufrufer hat also nicht die Wahl, ob er die Funktion synchron oder asynchron aufruft.

Schön finde ich, dass das %-Formating nicht depricated ist, sondern weiterentwickelt wird.

[jens]

Schön finde ich, dass das %-Formating nicht depricated ist, sondern weiterentwickelt wird.

Ach, ist das so? Das ja nett. Mit der neuen konnte ich mich nie wirklich Anfreunden...


Die Type-Annotations sind in der Tag sehr gewöhnungsbedürftig. Hätte es nett gefunden, wenn man es in die Doc-Strings gepackt hätte... Dann dienen sie auch der Dokumentation...

[BlackJack]

@jens: Naja wirklich weiterentwickelt wird ``%``-Formatierung doch eigentlich nicht — sie funktioniert jetzt halt auch (wieder) bei Bytestrings.

`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}'

[snafu]

Code: Alles auswählen

from typing import TypeVar, Iterable, Tuple

T = TypeVar('T', int, float, complex)
Vector = Iterable[Tuple[T, T]]

def inproduct(v: Vector) -> T:
    return sum(x*y for x, y in v)

Bevor ich eigene Typen für numerische Operationen definiere, würde ich mir aber zunächst mal im numbers-Modul nachschauen, ob dort nicht bereits ein passender Typ für mein Vorhaben bereitgestellt wird.

[snafu]

Mit den Type-Annotations hat sich Python 3 für mich wieder ein Stück weiter disqualifiziert, wenn jetzt alle Welt anfängt, Bibliotheken mit strikten Typ-Überprüfungen zu schreiben. Bei der async-Syntax bin ich mir noch nicht sicher, ob das wirklich der Weg ist, den man gehen sollte, oder ob das nur so ein Hype ist, der in 5 Jahren wieder sang- und klanglos in der Versenkung verschwindet.

Von Disqualifizierung will ich nicht direkt sprechen, aber ich sehe es ähnlich wie du, dass solche relativ massiven Änderungen bzw Erweiterungen an der Sprachsyntax, wie sie durch die Type-Annotations entstanden sind, zu ziemlich gruseligem Code führen können. (EDIT: Bei genauerem Hinsehen scheinen das gar keine Syntax-Erweiterungen zu sein, sondern es werden bereits bestehende Möglichkeit nur geschickt ausgenutzt.)

Die Entscheidung, `async` als Schlüsselwort einzuführen, halte ich für unklug. Da hätte man ruhig beim Status eines kleinen Frameworks als Teil der Standardbibliothek bleiben können, ohne die Sprache als solches anzufassen.

Einzig die Unpackingmöglichkeiten hätten schon viel früher umgesetzt werden sollen, weil sie wirklich manchen Code viel lesbarer machen.

+1

[BlackJack]

@snafu: Das da nicht im `numbers`-Modul geschaut wurde ist aber auch genau eines der Probleme: Viele Leute werden das nicht tun und Typen zu weit einschränken.

Auf der anderen Seite wird es Leute geben die sehr genau darüber nachdenken und für die lustigen Typsignaturen so schöne und umfangreiche Typhierarchien aufbauen werden wie bei Java. Wobei ihnen bei den abstrakten Basisklassen (ABCs) ja noch zusätzlich das Mittel zur Verfügung steht jede beliebige bestehende Klasse als Unterklasse von einer abstrakten Basisklasse zu registrieren. Das wird bestimmt voll übersichtlich. Juhuu. (Mir fällt gerade auf das wir keinen kotzenden Smiley zur Auswahl haben. )

Ich wünsche mir gerade das Python nicht (mehr) in Schulen oder Unis benutzt wird. Denn dort werden diese ”Typdeklarationen” *garantiert* zum Einsatz kommen, d.h. es wird viele Anfänger geben die das als erstes so lernen werden und es hinterher wieder verlernen müssen, und wahrscheinlich nicht oder nicht vollständig tun werden.

[cofi]

Ich mach mich mal unbeliebt und sage, dass ich die (fakultativen) Typdeklarationen toll finde, gerade weil sie auch Dokumentation darstellen.
Mein groesstes Problem damit ist nur leider, dass sie in der im PEP vorgestellten Art nicht zu Python passen und mehr oder weniger konkrete Typen darstellen statt die verwendeten Protokolle abzubilden.

Jetzt freu ich mich aber auf 3.6 und die f-Strings Wird so langsam mal Zeit das Tutorial abzustauben ...

[Hyperion]

Ich würde es mal so formulieren: Wieso sollte man in eine dynamisch typisierte Sprache statische Typen integrieren wollen? Imho gibt es in diesem Bereich eher kein sinnvolles "grau", sondern eben "schwarz" oder "weiß". Zumindest solange niemand bewiesen hat, dass eine Mischform wesentlich sinnvoller ist... und ob Python für solch einen Beweis die richtige Sprache ist, wage ich aufgrund der langen Vergangenheit zu bezweifeln.

Dabei gibt es imho so viel dringlichere Probleme... sei es nun ein ``encoding``-Parameter bei ``print`` (kleine Sache), "utf-8" als Standardencoding (etwas größere Sache) oder konzeptionelle Themen, wie einfache Parallelsierungsmöglichkeiten.

[cofi]

Wenn ich mich richtig erinnere vertritt Benjamin Pierce die Ansicht, dass dynamisches Typing ein Subset von statischem ist

Aber darauf will ich gar nicht hinaus. Es geht (fuer mich) nicht darum das Typing zu aendern, sondern Annahmen zu dokumentieren.
Ohne das belegen zu koennen wuerde ich sagen, dass der meiste Code bestimmte Typen erwartet und zwar eben nicht im Sinne von konkreten Typen, sondern im Sinne von bestimmten Eigenschaften.

[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?