On 18.01.2018 21:31, Achim Domma wrote:
Würde ich nur solchen Code zu sehen bekommen, ginge es mir wohl wie dir. Von daher kann ich jetzt zumindest deine "Begeisterung" für asyncio verstehen. ;-)
:) Mir ist in erster Linie wichtig, dass es funktioniert. Voreilige Optimierungen habe ich schon zur Genüge gesehen. Dafür hat es schon zu oft geklemmt, weil jemand meinte besonders schlau sein zu müssen. Wenn's brennt, dann muss es geradeaus gehen. Und im Endeffekt ist asyncio nichts anderes als eine Optimierung. Ich denke, da sind wir uns einig.
Nein, async und await sind nicht unbedingt high-level, aber eine höhere Abstraktion als select().
Vielleicht hinkt der Vergleich auch etwas. EventLoop.run_forever und while True: select(...) sind miteinander vergleichbar. async/await haben kein wirkliches Pendant.
Anderenfalls würde ich gerne hören, wie sich die asyncio-Gemeinde die Lösung des Zwei-Welten-Problems vorstellt. Zum Beispiel anhand von WSGI. Meinst du mit Zwei-Welten-Problem das Problem, den Übergang von asnyc Code zu sync bzw. umgekehrt? Exakt das löst async/await in meinen Augen exakt so gut, wie es in Python auf Grund der Natur der Sprache eben geht. Die zwei Welten sind nunmal unterschiedlich.
Na, das würde ich nicht so unterschreiben wollen. Deswegen auch das Beispiel mit dem WSGI. Richtig altmodisch klassisch hat man da einen Apache, der 20 WSGI-Worker mit Django zum Beispiel moderiert. Jeder Worker läuft in einem separatem Prozess. Dateien liefert der Apache alleine über eine entsprechende Kernel-Schnittstelle aus. Die Datenbank ist angebunden, 1 Worker 1 Connection üblicherweise. Wenn die Datenbank-Anfrage länger dauert, ist der Worker blockiert und kann keine anderen Anfragen beantworten. Es kann auch 10 bis 100 DB-Anfragen für einen WSGI-Request erfolgen, oder auch mal 10.000, wenn der Programmierer Mist gebaut hat. :D Jetzt die blöden Fragen: - wie fummelt man da asyncio hinein? Ich fürchte, das würde überhaupt nicht gehen. "Mal eben ausprobieren" wird hart. - *was wäre eigentlich die Zielsetzung?* Angenommen, man hätte das doch irgendwie geschafft: - wie stellt man sicher, dass, wenn die Abarbeitung eines Requests furios in, z.B., einem MemoryError scheitert, nicht auf einmal die anderen 100 Anfragen den Bach runtergehen? - wie stellt man sicher, dass nicht 1 fehlerhaft implementierter View (das ist das Ding, was für einen Request eine Response erarbeitet), alle anderen 100 Anfragen blockiert - await vergessen, oder so? Die Nachteile kooperativen Multitaskings bleiben bestehen, auch wenn diese totgeschwiegen werden. ;-) Ich kann mir gut vorstellen, dass asyncio bei einem kleinen, niedlichen, perfekt abgeschlossenen Projekt, wie einem HTTP-File-Server (wie z.B. nginx) super gut funktioniert. Da ist alles gut abgestimmt, niemand tritt sich gegenseitig auf die Füße und es gibt eig. nur 1 Funktion -> serve_file. Aber die meisten Web-Anwendungen, die Geschäftslogiken abbilden, sind dann doch eher ziemlich kompliziert/komplex und müssen ständig erweitert werden, wo ich mir gut vorstellen kann, dass man sich mit kooperativen Multitasking ziemlich sicher ins Knie schießt; auch je größer das Team wird. Da fehlen mir die Sicherungsmaßnahmen, die man bei einem separaten Prozess einfach hat.
Klar kannst du eine Sprache wie Go (bezogen auf deine andere Nachricht) explizit für das Szenario designen.
Ich hoffe ja noch immer bisschen auf golang-Einfluss. :D Aber bei vielen hier steht da noch das Ego im Weg.
Der Hauptkritikpunkt, den ich gelten lassen würde, ist, daß in den meisten Beispielen eben exakt der Übergang ausgespart wird. Ich hab' mir beim ersten mal auch den Wolf gesucht, bis ich die richtigen Funktionen zur Hand hatte. Und um sie zu benutzen, muß man schon ein solides Bild davon haben, was da passiert.
Ist man von Python eben nicht gewöhnt. So etwas fühlt sich dann an, wie wenn man von Python Ganzzahlen zu C int32 wechseln muss.
Nochmal mein Fazit: Ich halte async/await für die beste Abstraktion, die in Python geht.
Ich würde diese Aussage insoweit relativieren, dass es zur Zeit als die von vielen beste Abstraktion angesehen wird. Sven