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

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

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

Show key headers only | View raw

Sven R. Kunze schrieb am 18.01.2018 um 20:02:
> On 17.01.2018 22:49, Stefan Behnel wrote:
>> Und anstatt meinen Code speziell für asyncio zu schreiben, ist es dann
>> besser, ihn speziell für select() zu schreiben? Der "Vorteil" erschließt
>> sich mir absolut nicht. Bei asyncio brauche ich den meisten Code *gar
>> nicht* zu schreiben, weil es für fast alles schon fertige Tools und
>> Bibliotheken gibt, die ich dank der allgemeinen Schnittstelle einfach
>> ineinander stöpseln kann.
> 
> Sprichst du aus eigener Erfahrung?

Ja. Aber interessant, dass du es für nötig erachtest, explizit nachzufragen.


> Jemand anderes im Thread hatte nach
> genau solcher Erfahrung gefragt. Für mich liest sich das, was du da
> schreibst, leider immer noch nach einer Wiederholung des Marketings.

Was ja im eklatanten Gegensatz zu deinen eigenen Kommentaren steht. ;)


> Den asyncio-Quellcode, den ich bisher immer zu Gesicht bekommen habe,
> involvierte ab einer bestimmten Komplexitätsgrenze stets Threads.
> Wo ich mich dann naturgemäßg wieder frage, ob ich da im falschen Film bin,
> wo doch gerne so über Threads geschimpft wird.

Threads können genau zwei Dinge gut: 1) parallele Berechnung unabhängiger
Daten, also trivial-parallelen Code ausführen, und 2) nichts tun, z.B.
indem sie (im Rahmen vorhandener Ressourcen) auf I/O warten. Alles andere
führt ziemlich schnell zu Komplexitätsexplosion und sinkender Effizienz.

Daraus folgt: es ist nichts dagegen einzuwenden, Threads sinnvoll
einzusetzen, nämlich genau in den Bereichen, die sie gut abdecken.

Insbesondere bieten Thread-Pools eine gute (und simple) Möglichkeit,
synchrone Tools in die async-Welt zu integrieren, z.B. synchrone
Datenbanktreiber und SQLAlchemy, weil die Threads sich dort eben genau
auf's Nichtstun und unabhängige Datenverarbeitung beschränken lassen.


> Das Ineinander-Stöpseln, was ich da erlebt habe, war dann mit so einer
> riesigen Menge Boilerplate verbunden, dass ich diese Implementierung nicht
> wirklich ernstnehmen konnte. Für mich war es eher nur Show-Case anstelle
> einer Implementierung mit Mehrwert. Da wäre ich jetzt wirklich interessiert
> an realem Beispielen.

Um beim Beispiel zu bleiben, SQLAlchemy lässt sich mit ca. 10-20 Zeilen
leicht lesbarem Code mit Hilfe eines Thread-Pools in async-Frameworks
integrieren. Dann rufst du statt "query.all()" eben "await
background_query(query.all)" auf, und schon blockiert's nicht mehr und
erlaubt gleichzeitig 'unbegrenzten' I/O-Durchsatz. Empfinde ich jetzt noch
nicht als "riesige Menge Boilerplate", und funktioniert auch mit etlichen
anderen thread-sicheren synchronen APIs.


> Dennoch, die Problempunkte, die ich und viele andere immer wieder
> anbringen, werden auch hier nicht wirklich entkräftet und du gehst nicht
> ansatzweise darauf.

Na ja, selektiver Wahrnehmung ist eben schwer mit Argumenten zu begegnen.
Wenn es deine Meinung ist, dass asyncio der Teufel ist und alle anderen
schlicht nicht genug Erfahrung haben und im Zweifel nur noch nicht die
richtigen (furchtbaren) Code-Beispiele gesehen haben, die dich doch längst
in deiner Meinung verfestigt haben, dann helfen Argumente nur bedingt.

Klingt jetzt nach Ad-Hominem, ist mir klar, aber eigentlich beschreibt es
nur die Art, wie deine "Argumentation" in diesem Thread auf mich wirkt.


> Solange wir nur auf dem Niveau "meins ist besser" argumentieren, können wir
> hier auch aufhören.
> 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.

Du solltest die Möglichkeit in Erwägung ziehen, dass das vielleicht einfach
gar kein "Problem" ist, das eine "Lösung" erfordert. Das Neuschreiben von
Tools für async ist eigentlich nie ein Zwang, sondern entweder eine
Optimierung bestehender (sync-)Möglichkeiten, oder ein "cooles Projekt in
der Freizeit", oder irgendwas anderes, was Leute eben machen *wollen*.

So ist das halt bei OpenSource, niemand hält einen davon ab, das 5254.
Template-System zu schreiben, oder die 22. Neuimplementierung von Python,
"weil's ja so einfach ist" und "ich das viel besser kann als alle anderen",
oder weil ich vielleicht einfach etwas dabei lernen möchte. Genauso hält
einen niemand davon ab, ein cooles neues async-Tool zu schreiben, obwohl es
das alles "ja schon längst gibt". Leb einfach damit, dass andere Leute
Dinge machen, weil sie sie machen wollen, und nicht, weil du der Meinung
bist, dass sie sinnvoll sind. Andere Menschen haben andere Anforderungen
und andere Vorstellungen davon, was "sinnvoll" oder "cool" ist. Es gibt
auch genug Leute, die aus voller Überzeugung Java verwenden, weil's "cool"
ist. Kann man so oder so dazu stehen.

Stefan

Back to de.comp.lang.python | Previous | Next | Find similar

Thread

Re: [Python-de] select.epoll() vs async framework (PostgreSQL) Stefan Behnel <python-de@behnel.de> - 2018-01-19 11:17 +0100

csiph-web