Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Stefan Behnel Newsgroups: de.comp.lang.python Subject: Re: [Python-de] select.epoll() vs async framework (PostgreSQL) Date: Wed, 17 Jan 2018 22:49:12 +0100 Lines: 43 Message-ID: References: <29ce1adc-0fea-e23c-e321-858e0d52dc1c@thomas-guettler.de> <71ab86cc-0e21-da2f-9577-8b6ccbe707ba@thomas-guettler.de> <2915505E-9237-40C4-A2BF-A4A22D00A216@web.de> <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <9ce770aa-b6dd-f709-1a95-f1e02f82f7f6@mail.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: news.uni-berlin.de T59VJUgi/4lDR/1KR/cLUQ1KTCOqR61NLsN1+LwKYrpA== Return-Path: X-Original-To: python-de@python.org Delivered-To: python-de@mail.python.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1516225948; s=strato-dkim-0002; d=behnel.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Date:Message-ID: From:References:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=hUQEuqlUEBsTs9b8X9H1Uc6KOmvm8h8HAi28vE4YMUs=; b=nAqdfAf1XTw90fvgsjQHFKbtnmUdTum4/NLbfThfeoZwAMvwuoglepyMQ1bySAWg8h ux8dHwJES54cqgDGJtI+19mxx165cX7AdBIS7gypqf3PUrkCEpctggnUkKZdGwnnoalL G1aLlqrF8RGkZldPTF6iPxLSQNxZmBBkqvOjfWxELSwGHOezDClmrkYCYTBVSKqKK9d7 YEyrhxziM1h2kq9PTH107u9Z33SeDhc4VH33YY1QAqD1rfHX9hzyfjlod4nzKZCNrr6l BXFpgeToV7+aUgV0VtOB1ACQcCK44lU7m+ADVvdYgqAcDK8MPpYsiSOy6zlSb9yU0r/R zpgg== X-RZG-AUTH: :E1MMdFW4b++AXZOTwA41DOYM0Dv9LNWvavC/fJZ6Wfgmp/Lh1ANWCRaaq2R1hCooD/t2Vl9QPVeBUNbEes6Rl1idG4gud7BD4hV37e0/2ZHKlCEy X-RZG-CLASS-ID: mo00 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 In-Reply-To: <9ce770aa-b6dd-f709-1a95-f1e02f82f7f6@mail.de> Content-Language: de-DE X-BeenThere: python-de@python.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Die Deutsche Python Mailingliste List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <29ce1adc-0fea-e23c-e321-858e0d52dc1c@thomas-guettler.de> <71ab86cc-0e21-da2f-9577-8b6ccbe707ba@thomas-guettler.de> <2915505E-9237-40C4-A2BF-A4A22D00A216@web.de> <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <9ce770aa-b6dd-f709-1a95-f1e02f82f7f6@mail.de> Xref: csiph.com de.comp.lang.python:5082 Sven R. Kunze schrieb am 17.01.2018 um 19:36: > On 16.01.2018 19:55, Stefan Behnel wrote: >> Sven R. Kunze schrieb am 15.01.2018 um 20:55: >>> 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. > > 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. 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. 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. Wenn dich jemand bittet, eine Webseite zu entwickeln, ist dann dein erster Schritt, das HTTP-Protokoll zu implementieren? Ganz ehrlich, die Begriffe "asyncio", "async/await" und "kooperatives Multitasking" haben zwar durchaus etwas miteinander zu tun, sind aber nicht gleichbedeutend. Sie sind alle nur (sehr allgemeine) Werkzeuge, mit denen sich alles Mögliche machen lässt. Deine bisherige Kritik scheint sich an einer ziemlich schmalen Kombination der drei Begriffe aufzuhängen, die weder Nutzen noch Anwendungsbereich auch nur annähernd abdeckt. Stefan