Sven R. Kunze schrieb am 15.01.2018 um 20:55:
On 15.01.2018 17:07, Diez B. Roggisch wrote:
On 15. Jan 2018, at 16:46, Thomas Güttler wrote: Was ist aus deiner Sicht das, was alle nehmen? Ich rate mal: asyncio. Die Chance, das du zB http-clients da einfach einpluggen kannst, und damit schon auf einem deutlich besseren Abstraktionsniveau unterwegs bist, als mit rohen Filedeskriptoren und epoll zu arbeiten laesst mich vermuten, dass es sich dabei um das Alufelgenrad handelt.
Aus meiner Sicht gequilter Unsinn. asyncio is ein Nischenprodukt und alle Welt verwendet File-Deskriptoren. Wunschdenken sollte nicht mit der Realität verwechseln werden.
Sockets sind meiner Meinung nach ein viel besseres Abstraktionsniveau als meinen Quellcode überall mit diesem dämlichen async und await zu spicken.
Ich verstehe nicht, warum das ein Argument dafür sein sollte, sich seinen eigenen I/O-Loop zu schreiben. AsyncIO wurde exakt und einzig und allein aus dem Grund geschrieben, dass es bereits zu viele davon gab, die alle nicht miteinander kompatibel waren. Wenn Thomas also jetzt darüber nachdenkt, sein handgedrechseltes select() noch weiter zu einem solchen auszubauen, dann nehme ich das als Anreiz, auf die vergleichbaren Fehler anderer hinzuweisen, aus denen bereits nachhaltig Lehren gezogen wurden. Ein hübsches Ergebnis ist jetzt z.B., dass das Tornado Web-Framework in der Version 5 komplett auf asyncio umziehen wird und in der Folgeversion den eigenen I/O-Loop über den Jordan jagt. Das große Aufräumen hat begonnen. Und eine zweite Implementierung von asyncio gibt es mit uvloop auch schon, so dass jetzt auf beiden Seiten der Schnittstelle die freie Auswahl besteht. AsyncIO ist auf dem besten Weg, für die Welt des kooperativen Multitaskings so etwas zu werden wie WSGI es seit Jahren schon für synchrone Web-Frameworks ist. Stefan