Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #5076
| From | Achim Domma <domma@procoders.net> |
|---|---|
| Newsgroups | de.comp.lang.python |
| Subject | Re: [Python-de] select.epoll() vs async framework (PostgreSQL) |
| Date | 2018-01-16 22:24 +0100 |
| Message-ID | <mailman.97.1516138351.2620.python-de@python.org> (permalink) |
| References | (4 earlier) <04ab7b73-e182-081c-74c7-976e3eac9b84@mail.de> <BF99A7B0-1BA4-4C3D-A9BF-B8968881C85D@web.de> <mailman.78.1516099885.2620.python-de@python.org> <slrnp5spfk.v6s.hjp-usenet3@hrunkner.hjp.at> <70c7171a-cffc-538e-80f3-63419c4b2586@procoders.net> |
Hi, neben der Tatsache, daß ich die Umgangsformen auf dieser Liste immer wieder befremdlich finde, wundert es mich, wieviele Menschen scheinbar der Meinung sind, ihre kleine Welt wäre alles, was es da draußen gibt. Ja, ich finde async-Code auch nicht unbedingt schön. Aber das liegt auch im Problem begründet. Wenn ich die Funktionalität nutzen will, habe ich aber auch noch nichts eleganteres in Python gesehen. Ich mußte mal 80Mio eher kleine Files auf einer 64 Core Maschine mit dicker Leitung möglichst schnell von S3 runter laden. Mit der asyncio Version von botocore war das ziemlich wenig Code und kein Kollege kam auch nur annähernd an die Performance ran. Klar muß man asyncio dazu verstehen und vorher bißchen Doku lesen. ;-) In anderen Fällen bin ich SEHR großer Fan von ZeroMQ. Die Betonung liegt auf "anderen". Es hängt halt vom Anwendungsfall ab. Ich habe mir sagen lassen, daß es auch Menschen gibt, die mit "dickeren" Messagequeues gut fahren. Bei mir war das nie der Fall, was aber wohl an "meiner Welt" liegt. Deshalb sind die Produkte aber nicht automatisch scheiße. Und davon abgesehen ist auch die Entscheidung, ob man etwas selbst implementiert oder eine bestehende (neue hippe?) Lösung nimmt, nicht immer ganz soooo eindeutig. Ich bin großer Fan davon, immer den neuesten coolen Scheiß zu benutzen. Trotzdem weiß ich, daß es manchmal eine schlechte Idee ist. Nur um die Diskussion mal ein bißchen in die richtige Perspektive zu setzen! ;-) viele Grüße, Achim PS.: Um aber auch ein bißchen zu pauschalisieren: Die alten Typen, die alle neuen Technologien schon damals in den 80ern, 70ern, ... benutzt hatten, waren in meiner Welt bisher immer Klugscheißer, die zu faul waren, sich mit neuen Sachen zu beschäftigen.
Back to de.comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Diez B. Roggisch" <deets@web.de> - 2018-01-16 11:38 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-16 21:52 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Diez B. Roggisch" <deets@web.de> - 2018-01-16 22:24 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-19 06:47 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-19 17:09 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-20 09:53 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-24 12:41 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) Achim Domma <domma@procoders.net> - 2018-01-16 22:24 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) Wolfgang Strobl <news4@mystrobl.de> - 2018-01-18 07:06 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-17 18:32 +0100
Re: [Python-de] select.epoll() vs async framework (PostgreSQL) "Sven R. Kunze" <srkunze@mail.de> - 2018-01-17 18:48 +0100
csiph-web