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

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

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

Show key headers only | View raw

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? 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. 
Quellcode wäre gut.

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.

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.

> Bei einem blanken select() (oder epoll() usw.) fange ich dagegen komplett
> bei Null an, weil ich damit faktisch auf der Socket-Ebene festhänge, also
> ganz, ganz unten. Dann brauche ich erst einmal Tools, die inkrementell auf
> Sockets lesen und schreiben können, und die muss ich dann auch noch mühsam
> orchestrieren. Also muss ich genau die (fehleranfällige) Arbeit selbst
> machen, die mir ein I/O-Loop fertig (und fertig debuggt) abnimmt. Für
> nichts anderes ist doch ein I/O-Loop da.

Ich bin durchaus in den allgemeinen Prinzipien der Software-Entwicklung 
bewandert.

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

Natürlich ist es schön, Code wiederzuverwenden, das gilt aber sowohl für 
den tollen neuen asyncio-Code als auch für den bereits geschriebenen 
alten langweiligen sync-Code.
Natürlich ist es schön, nicht an unterster Ebenen festzuhängen, aber 
async und await sind jetzt nicht wirklich high-level und select nimmt 
einem mega viel Arbeit, die ich nicht programmieren möchte, ab.

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.


Sven

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

Thread

Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-18 20:02 +0100

csiph-web