Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.python > #5081

Re: [Python-de] select.epoll() vs async framework (PostgreSQL)

From "Sven R. Kunze" <srkunze@mail.de>
Newsgroups de.comp.lang.python
Subject Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
Date 2018-01-17 19:36 +0100
Message-ID <mailman.107.1516214204.2620.python-de@python.org> (permalink)
References (2 earlier) <71ab86cc-0e21-da2f-9577-8b6ccbe707ba@thomas-guettler.de> <2915505E-9237-40C4-A2BF-A4A22D00A216@web.de> <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <d1a40b67-1a37-7164-f980-85d473a0838e@behnel.de> <9ce770aa-b6dd-f709-1a95-f1e02f82f7f6@mail.de>

Show all headers | View raw


On 16.01.2018 19:55, Stefan Behnel wrote:
> Ich verstehe nicht, warum das ein Argument dafür sein sollte, sich seinen
> eigenen I/O-Loop zu schreiben.

Weil, wie du an anderen Antworten hier im Thread und auch an verlinkten 
Resourcen merkst, dies ein riesengroßes Problem darstellt.

Da verstehe ich nicht, warum nicht proaktiv auf dieses Problem 
eingegangen wird. Kein normaler Programmierer will alle seine 
Bibliotheken auf eine zweite Programmiersprache umschreiben. Das ist das 
Zwei-Welten-Problem bei asyncio. Stattdessen höre ich immer nur: "du 
machst das falsch", "asyncio ist die Zukunft" etc.

Darüber hinaus sehe ich noch ein weiteres Problem: wenn async+await 
tatsächlich die Zukunft darstellen sollen, dann sollte ja auch deren 
Verwendung ziemlich stark zunehmen. Wenn dann also jeder Funktionsaufruf 
mit einem await versehen und jede Funktionsdefinition mit einem async 
versehen worden ist, dann macht es doch überhaupt keinen Sinn mehr?

Mag sein, dass ich hier zu weit in die Zukunft denke, aber eine 
technische Mischwelt halte ich für fast unmöglich und wurde mir auch von 
vielen erfahrenen Entwicklern bestätigt. Entweder async-Welt oder sync-Welt.
Allerdings sagt mir meine Erfahrung: man braucht einen sanften 
Migrationsweg oder man hat gar keine Migration. Und das sehe ich noch 
als riesiges Problem.

> 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.

select ist doch eine Standardfunktion. Was ist daran handgedrechselt? 
Meinst du die Schleife in der das select vorkommt?

> 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.

Das ist schön für das kooperative Multitasking. Aber die Probleme beim 
Übergang von einer in die andere Welt bleiben und die sollte man nicht 
totreden oder schweigen.

Sven

Back to de.comp.lang.python | Previous | NextNext in thread | Find similar


Thread

Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-17 19:36 +0100
  Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-19 06:58 +0100

csiph-web