Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
On 2018-01-19 16:33, Sven R. Kunze
On 18.01.2018 23:50, Achim Domma wrote:
Vermutlich wird niemand eine GUI basierend auf asyncio entwickeln wollen.
Kannst du erläutern, wieso nicht?
Würde mich auch interessieren. Prinzipiell scheint mir asyncio besser für GUI-Programmierung geeignet zu sein als der traditionelle event-basierte Stil (schon klar, letzteren sind die Leute seit 30 Jahren gewohnt). hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Peter J. Holzer schrieb am 20.01.2018 um 10:02:
On 2018-01-19 16:33, Sven R. Kunze wrote:
On 18.01.2018 23:50, Achim Domma wrote:
Vermutlich wird niemand eine GUI basierend auf asyncio entwickeln wollen.
Kannst du erläutern, wieso nicht?
Würde mich auch interessieren. Prinzipiell scheint mir asyncio besser für GUI-Programmierung geeignet zu sein als der traditionelle event-basierte Stil (schon klar, letzteren sind die Leute seit 30 Jahren gewohnt).
Ich vermute, du beziehst dich hier eher auf den Programmierstil mit async-Koroutinen als auf asyncio, aber bezüglich letzterem: Üblicherweise bringen GUI-Frameworks (wie GTK oder Qt) ihren eigenen I/O-Loop mit, also verwendest du eigentlich auch schon "seit 30 Jahren" so etwas ähnliches wie asyncio. Die Konsolidierung an der Stelle würde also vermutlich eher so aussehen, dass jemand eine asyncio-API für diese implementiert, um auch async-Netzwerk-Frameworks zusammen mit GUIs in einer Anwendung laufen lassen zu können. Bisher war so etwas immer ein ordentliches Gefrickel, weil irgendwelche Sockets aus beiden zusammen gesammelt und durchgereicht werden mussten. Oder es mussten doch wieder zwei Threads laufen, die dann umständlich abgesichert und trotzdem fehleranfällig ihre Daten austauschen mussten. Stefan
participants (2)
-
Peter J. Holzer -
Stefan Behnel