Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Stefan Schwarzer <sschwarzer@sschwarzer.net>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
Date: Sat, 20 Jan 2018 00:02:48 +0100
Lines: 96
Message-ID: <mailman.159.1516402977.2620.python-de@python.org>
References: <29ce1adc-0fea-e23c-e321-858e0d52dc1c@thomas-guettler.de> <a1669a00-b66c-6cce-8546-570a857e77aa@behnel.de> <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> <bc8618a5-2ffc-46eb-72a4-afa12ddc030d@behnel.de> <374d8f30-d5ec-a097-6bd0-ce15fc0d824e@mail.de> <fea78855-045d-377b-5acd-75de5dab4d18@behnel.de> <0f1b475c-3af3-9baa-860a-1d3baa57f8c3@sschwarzer.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666
In-Reply-To: <fea78855-045d-377b-5acd-75de5dab4d18@behnel.de>
Content-Language: de-DE
Precedence: list
Xref: csiph.com de.comp.lang.python:5101

On 2018-01-19 11:17, Stefan Behnel wrote:
> Sven R. Kunze schrieb am 18.01.2018 um 20:02:
>> On 17.01.2018 22:49, Stefan Behnel wrote:
>> 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.

Mich würde es sehr interessieren, diesen "leicht lesbaren"
Code zu sehen. :-) Ist der auch leicht lesbar für jemanden,
der mit asyncio noch relativ wenig Erfahrungen hat?

Wie schwierig ist es unter diesen Umständen, selber auf
diesen Code zu kommen?

Ein weiterer Punkt: Ist das generischer Code, der sich auch
auf andere synchrone APIs anwenden lässt oder ist es
überwiegend Code, der speziell auf SQLAlchemy zugeschnitten
ist?

>> 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 habe ich zwar auch schon überlegt, dass es so sein könnte,
aber bisher habe ich nichts konkretes gesehen, was mich davon
überzeugen würde.

> 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.

Ich habe ja überhaupt kein Problem damit, wenn Leute etwas aus
Interesse entwickeln. Ich finde es nur unschön, wenn man diese
zusätzlichen (gegenüber den synchronen Libraries) entwickeln
_muss_, um sie im asyncio (im Sinne von `async`/`await`) nutzen
zu können.

Ein paar Gedanken zur Vermittlung von Asyncio in Python:

Die meisten Artikel, die ich dazu bisher gesehen habe, sind
Einführungen anhand relativ einfacher Beispiele. Um den Leser
nicht gleich zu "erschrecken", werden Aufgabe und Lösung so
gewählt, dass sie gut ins Asyncio-Paradigma bzw. den Support
dafür in Python passen.

Aber wie geht es weiter, wenn man sich nicht nur einen Überblick
verschaffen, sondern Pythons Asyncio in "richtigen" Projekten
einsetzen will? Da habe ich bisher extrem wenig Dokumentation
zu gefunden. Ich glaube, das hier geht in die richtige Richtung:
https://pymotw.com/3/asyncio/index.html .

Auf der anderen "Seite" von Einsteiger-Tutorials finden sich die
technisch ausführliche Dokumentation wie die unter
https://docs.python.org/3/library/asyncio.html . Da mag zwar alles
drin stehen, aber als Einsteiger sieht man den Wald vor lauter
Bäumen nicht. Das ist, wie eine natürliche Sprache aus einem
Wörterbuch und einer Grammatik-Referenz lernen zu wollen.

Kennt ihr weitere Webseiten und gegebenenfalls Bücher, die den
Einsatz von Python-Asyncio in nicht-trivialen Projekten erläutern?

Stefan, ich hatte auch schon überlegt, dir vorzuschlagen, dazu
einen Vortrag auf der PyCon DE zu halten. Ich fürchte aber, dass
ein Vortrag nicht das richtige Medium dafür ist bzw. in der
verfügbaren Zeit kaum über eine Asyncio-Einführung hinauskommt.
Was meinst du?

Viele Grüße
Stefan