Mailman 3 January 2018 - python-de

Berliner PUB-/DZUG-Treffen am 17.9. um 19 h im newthinking store
by Dinu Gherman 04 Sep '22

04 Sep '22

Liebe Python-Freunde, diesen Donnerstag, den 17.8.2009 (übermorgen!) findet wieder ein PUB/DZUG-Treffen (Python und Zope User Group in Berlin) statt. Ort und Zeit sind wie immer: 19 Uhr, im newthinking store [1]. Anschließend wird das Treffen wieder im Restaurant Tucholsky [2] fortgesetzt. Zur Planung der Restaurantkapazitäten bitte ich euch ein Häckchen in der Doodle-Umfrage [3] zu machen, wenn ihr an- schließend noch mitkommen wollt. Das Programm muss dieses mal etwas kurzfristig arrangiert werden. Wer also schon immer mal einen kurzen Vortrag halten wollte, z.B. zu einem der Themen im Python-Wiki [4] und diesen womöglich schon in der Schublade hat, der (oder die) ist herzlich dazu eingeladen. Dann bitte bei mir vorher kurz per E-Mail ankündigen! Ansonsten werden einige, die auf der DZUG-Tagung letzte Woche in München waren, locker darüber berichten. Dabei ging es unter an- derem über die kommenden Versionen 4 und 5 von Plone. Sehr wahr- scheinlich wird Veit dazu Prospekte verteilen. Eine weitere Idee besteht darin, locker Buchempfehlungen zu den Themen Python/Zope/Plone auszutauschen, was man am besten macht, indem man das jeweilige Buch auch zum Treffen mitnimmt. Ich werde am Donnerstag das Buch "Python for Linux and Unix System Admini- stration" [5] dabei haben. Liebe Grüße und bis Donnerstag, Dinu PS: Ich übernehme mit Veit bis auf Weiteres die Organisation die- ser Treffen von Stephan, der das bisher vorbildlich gemacht hat, aber nun seinen väterlichen Aufgaben höhere Priorität geben wird. Nochmals vielen Dank, Stephan - ich hoffe, Du kannst trotzdem noch vorbeischauen! [1] newthinking store, Tucholskystr. 48, 10117 Berlin, http://newthinking-store.de [2] Restaurant Tucholsky, Torstraße 189, 10115 Berlin, http://www.restauration-tucholsky.de [3] http://doodle.com/rwqizz6ewxk6iscw [4] http://wiki.python.de/User%20Group%20Berlin [5] http://www.oreilly.de/catalog/9780596515829 ...................................................................... Follow me on Twitter: http://twitter.com/dinugherman

2 1

Re: [Python-de] seltsames Verhalten mit acme_tiny.py, wie löse ich es?
by Peter J. Holzer 31 Jan '18

31 Jan '18

On 2018-01-31 17:33, Walter H. <Walter.H-Nntp(a)mathemainzel.info> wrote: > ich verwende f. Let's Encrypt dieses > https://github.com/diafygi/acme-tiny > Script ... > > mein Router hat - klarerweise - mehrere NICs, und er ist vollständig > DualStack; [...] > wenn ich nun mit diesem Skript das Zertifikat f. IPv6 erneuern will > kommt das ... > > Parsing account key... > Parsing CSR... > Registering account... > Already registered. > Verifying host.ipv6home.eu... > Traceback (most recent call last): > File "./acmetiny.py", line 198, in <module> > main(sys.argv[1:]) > File "./acmetiny.py", line 194, in main > signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, > log=LOGGER, CA=args.ca) > File "./acmetiny.py", line 123, in get_crt > wellknown_path, wellknown_url)) > ValueError: Wrote file to > /var/www/inet/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS0qh-EJmUOpVLGcz22KY, > but couldn't download > http://host.example.com/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS… Hmm. Inkonsistent anonymisierte Hostnamen (einmal "host.ipv6home.eu", einmal "host.example.com") sind kontraproduktiv. Da weiß man nicht, ob die unterschiedlich sind, weil die Originalnamen auch unterschiedlich waren, oder weil Du beim Anonymisieren schlampig warst. Wenn Dein Server eine öffentliche IPv4-Adresse hat, ist es ohnehin sinnlos, den geheim halten zu wollen. Die ersten Bots haben den sicher wenige Minuten, nachdem er eingeschaltet wurde, entdeckt. > im Skript selbst habe ich folgendes gefunden, wenn ich diesen Teil hier > > # check that the file is in place > wellknown_url = > "http://{0}/.well-known/acme-challenge/{1}".format(domain, token) > try: > resp = urlopen(wellknown_url) > resp_data = resp.read().decode('utf8').strip() > assert resp_data == keyauthorization > except (IOError, AssertionError): > os.remove(wellknown_path) > raise ValueError("Wrote file to {0}, but couldn't download > {1}".format(wellknown_path, wellknown_url)) > > auskommentiere, dann klappt das; hingegen mit habe ich dieses Problem > nicht; daher die Frage: woher kommt dieses Verhalten mit IPv6? > da es auch mit deaktivierter Firewall ist, wird es auch nicht durch > irgendeine Regel verursacht ... > (im Log des Apache sehe ich keine Zugriffe derart, sprich es wird vorher > bereits blockiert) Hast Du ein /etc/hosts, in dem host.example.com definiert ist? acme-tiny versucht zuerst selbst, die Challenge zu überprüfen, bevor es die CA bemüht. Das geht aber natürlich nur, wenn der Server vom gleichen Rechner aus unter dem gleichen Namen erreichbar ist. Manche Linux-Distributionen schreiben so Zeug wie "127.0.1.1 meinname" da rein. Oder manchmal vergisst man, das nach einer Adressänderung zu editieren. Das führt dann zu Effekten wie dem von Dir beobachteten (das hat mich auch mal geraume Zeit gekostet). hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

1 0

Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
by Stefan Behnel 24 Jan '18

24 Jan '18

Hallo Sven, ich vermute mal, du wolltest deine Antwort eigentlich an die Liste schicken, also hier meine Antwort öffentlich. Sven R. Kunze schrieb am 24.01.2018 um 12:21: > On 23.01.2018 06:29, Stefan Behnel wrote: >> Sven R. Kunze schrieb am 22.01.2018 um 17:14: >>> Mit anderen Worten, wenn ich in den Projekten bereits einen >>> Aufgaben-Verteiler-Prozess (Steuerprozess) habe, dann brauche ich mir um >>> asyncio eigentlich keine Gedanken zu machen. >> Doch, denn genau das war ja der Aufmacher für diese Diskussion. Es lohnt >> sich oft, einen wie auch immer existierenden (async-)Steuerprozess durch >> asyncio zu ersetzen, weil dadurch ein ganzer Haufen wiederverwendbarer Code >> verfügbar wird. > > Durchaus richtig, wenn wir den Steuerprozess betrachten. Dann macht > Referenz auf asyncio schon Sinn. > > Nur leider kann man die asyncio-Loop nicht ohne async/await nutzen. Ah, ja, ich dachte mir schon, dass das deine Annahme ist. Das stimmt aber nicht. > Ich > denke, dadurch zwing man viele Leute in eine Richtung, die sie gar nicht > gehen wollen. Für mich sind das zwei getrennt Dinge, denn bisherige > Steuerprozesse konnten bisher ThreadPools/ProcessPools auch gut ohne > async/await launchen. Vielleicht ergibt sich da ja etwas in der Zukunft, > die standardisierte asyncio-Loop ohne await/async zu verwenden. Sicherlich > ist das nicht so IO-performant, aber es ging vorher ja auch ganz gut ohne. Dann habe ich eine gute Nachricht für dich: du kannst jederzeit Dinge außerhalb des I/O-Loops machen, auch ohne async/await. asyncio unterstützt natürlich async/await, und das ist auch die empfohlene Art, asyncio-Code unter Py3.5+ zu schreiben, aber weder ist asyncio auf async/await beschränkt, noch ist async/await auf I/O (oder asyncio) beschränkt, sondern implementiert nur eine Art von Koroutinen. Und mit "async with" und "async for" gibt es dazu noch zwei recht mächtige Sprachkonstrukte, die verschiedene Kooperationsmuster zwischen Koroutinen sehr sauber kapseln. > Ich kann abrupte Migrationen nicht leider. > > Darüber hinaus ist es auch oft nicht möglich, den Steuerprozess so einfach > zu ersetzen, z.B. Apache WSGI. WSGI ist kein Steuerprozess, sondern eine API. Genauso wie asyncio eine API ist. Es gibt durchaus WSGI-Implementierungen auf asyncio-Basis, aber wie du weiter oben schon selbst anmerktest, nutzen die die Möglichkeiten eines asynchronen I/O-Loops nicht aus. Insbesondere Latenz und Nebenläufigkeit leiden natürlich sehr, wenn zu viel in dem synchronen WSGI-Aufruf außerhalb des I/O-Loops passiert (z.B. ganze Datenbankabfragen usw.). Allerdings gäbe es durchaus die Möglichkeit, WSGI so zu erweitern, dass statt eines Generators eine Future zurück geliefert wird. Dann ließe sich das Interface auch wieder async bauen. Und da die Idee so offensichtlich ist, haben es andere vermutlich auch schon ausprobiert. Andersherum, also async auf sync (dein "Apache WSGI"), wüsste ich jetzt gerade nichts, aber das heißt weder, dass es nichts gibt, noch, dass es grundsätzlich nicht geht. Wenn's dich interessiert, kannst du ja mal ein bisschen suchen, oder selbst etwas ausprobieren. >> Du hast von einem sync/async Zwei-Welten-Problem gesprochen, aber das >> wirkliche Problem war die Zersplitterung innerhalb der async-Welt. Das ist >> das, was asyncio beseitigt. > > Nun das Problem scheint ja nun erstmal behoben zu sein. Das > Zwei-Welten-Problem bleibt leider. Und ist zumindest aus meiner Sicht, das > größere; YMMV. Ceterum censeo ... Stefan

1 0

Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
by Peter J. Holzer 24 Jan '18

24 Jan '18

On 2018-01-19 16:09, Sven R. Kunze <srkunze(a)mail.de> wrote: > On 19.01.2018 06:47, Peter J. Holzer wrote: >> Nein, aber die Idee ist nicht so absurd, wie Du glaubst. >> >> (Abgesehen davon glaube ich nicht, dass Dein Vorposter das wollte. Für >> micht klingt das eher, als wollte er einen HTTP-Parser und/oder >> -Generator im Kernel haben (wobei mir nicht ganz klar ist, wozu) und >> sowas würde als Teil etwa einer Firewall- oder WebDAV-Komponente wenig >> Stirnrunzeln auslösen.) > > Damit der konkrete Anwendungsfall klarer wird. > Aufgabe war/ist es URLs asynchron zu callen und den Rückgabewert in eine > DB zu schreiben (siehe erster Post dieses Threads). > > Nun stellte sich leider heraus, dass eine URL zu requesten nicht > wirklich einfach ist. Die Lib "requests" auf jeden Fall ist ziemlich > blocking und insbesondere muss es mehrere blockierende Dinge > nacheinander tun. Im einfachsten Fall: > 1) DNS lookup > 2) open connection > 3) push request data on socket Also einen HTTP-Client bzw. Proxy (nach außen soll er HTTP sprechen, zur Applikation (möglicherweise) etwas anderes). > Meine naive Lösungsvorstellung war: ein Socket, der genau alles das > kann, was requests kann. Du musst also "alles, wes requests kann" auf ein Protokoll abbilden. Wie wird dieses Protokoll aussehen? Da requests ein API für HTTP ist, würde ich annehmen, dass man natürlicherweise entweder bei HTTP oder etwas sehr ähnlichem landet (ein paar historische Unfälle könnte man sicher beheben: Z.B. braucht man nicht 3 verschiedene Methoden, das Ende eines Requests anzuzeigen). > Damit würde die select-loop extrem einfach werden, Glaube ich nicht, denn Du musst jetzt dieses Protokoll sprechen. Das wird aber ähnlich komplex sein wie HTTP, also nicht "extrem einfach". Es sei denn, man lässt Features weg: Aber dann kann es nicht mehr alles, was requests kann, und wäre nur mehr für spezielle Fälle brauchbar (die zwar wahrscheinlich eh 90% aller Anwendungen ausmachen, aber wenn man sowas als Funktion des Betriebssystems zur Verfügung stellt, dann will man natürlich 100% abdecken). Und da denke ich mir, Du kannst gleich HTTP sprechen (das macht man ja auch über einen Socket). Und weil oben schon das Stichwort Proxy gefallen ist: Was spricht dagegen einen solchen Procy mit den Features, die Du haben willst, du schreiben? > Die andere Seite (nämlich das NOTIFY von PostgreSQL) ist genau so > einfach. 1 Socket, von dem man liest. Hmm? Auf dem Socket musst Du aber das PostgreSQL-Protokoll sprechen. Ich nehme an, dafür verwendest Du psycopg2 und hast das nicht selbst implementiert? Das scheint mir jetzt nicht sonderlich event-loop-freundlich zu sein. Wenn Du nur NOTIFY brauchst, ok. Und einfache Querys gehen auch noch (dürften aber schon etwas komplexer sein). Aber sobald Du Transaktionen brauchst, hast Du (laut Manual) verloren. Da würde mich interessieren, wie das mit async/await aussieht: Laut Manual gibt es "Support for coroutine libraries", aber das ist recht vage und asyncio wird nicht mal erwähnt. Hat jemand damit praktische Erfahrungen? hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

2 1

select.epoll() vs async framework (PostgreSQL)
by Thomas Güttler Lists 23 Jan '18

23 Jan '18

Hallo, bisher nutze ich psycopg (PostgreSQL) zusammen mit Linux select.epoll() und das klappt eigentlich ganz gut. Bisher nutze ich kein async IO framework. Jetzt soll neben der Datenbank Connection auch noch N URLs geholt werden. Aktuell ist N < 1000. Also weniger als 1000 URLs die gleichzeitig geholt werden. Jetzt bin ich unsicher, ob ich: Variante1: die N URLs auch per select.epoll() hole. Variante2: auf ein async IO Framework umsteige. Hat hier jemand Erfahrung und kann ggf etwas aus dem Nähkästchen plaudern? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

8 27

Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
by Peter J. Holzer 20 Jan '18

20 Jan '18

On 2018-01-19 16:33, Sven R. Kunze <srkunze(a)mail.de> 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). hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

2 1

Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
by Peter J. Holzer 19 Jan '18

19 Jan '18

On 2018-01-16 21:24, Diez B. Roggisch <deets(a)web.de> wrote: >> Am 16.01.2018 um 21:52 schrieb Peter J. Holzer <hjp-usenet3(a)hjp.at>: >> >> On 2018-01-16 10:38, Diez B. Roggisch <deets(a)web.de> wrote: >>>> Sockets sind meiner Meinung nach ein viel besseres Abstraktionsniveau >>>> als meinen Quellcode überall mit diesem dämlichen async und await zu >>>> spicken. >>>> >>>> Das einzige, was hier fehlt, wäre ein spezieller Typ von >>>> File-Deskriptor, der entsprechend in der Lage ist HTTP zu sprechen. >>> >>> Du moechtest also einen HTTP-Server in den Kernel verlagern? >> >> Gab es bei Linux schon. > > Und hat NGINX und Apache erfolgreich verdrängt wie wir jeden Tag sehen. Nein, aber die Idee ist nicht so absurd, wie Du glaubst. (Abgesehen davon glaube ich nicht, dass Dein Vorposter das wollte. Für micht klingt das eher, als wollte er einen HTTP-Parser und/oder -Generator im Kernel haben (wobei mir nicht ganz klar ist, wozu) und sowas würde als Teil etwa einer Firewall- oder WebDAV-Komponente wenig Stirnrunzeln auslösen.) >>> Wo wir dabei sind, gleich noch ne RDBMS-engine? >> >> War das nicht für Windows 2000 geplant? > > Weiß nicht genau was du meinst. Das nie erschienene WinFS für > Longhorn? Das war jedenfalls eher eine Desktop-Suche Ja, aber meiner Erinnerung nach war das deutlich mehr als nur eine Desktop-Suche. > wie Spotlight, und zumindest letzteres ist über Worker im Userspace > implementiert. Man kann jedes Feature im Userspace oder im Kernel implementieren. NFS-Server sind traditionell im Kernel implementiert, aber die erste Linux-Implementation war im Userspace. Der SMB-Server ist unter Linux im User-Space implementiert (Samba), bei Windows bin ich mir nicht sicher, aber glaube, das ist im Kernel (was jetzt immer bei Windows genau der Kernel ist). Microkernel-Betriebssysteme lagern praktisch alles, was man in der Unix-Welt als Aufgabe des Betriebssystems sieht (Filesysteme, Memory-Management, sogar Scheduling) in den Userspace aus. >> Strukturierte Files waren in den 70ern durchaus üblich. Unix war da mit >> seinem radikalen Minimalismus eher die Ausnahme. > > Haben die beliebige Abfragen und Aggregationen über ihre Felder > erlaubt? Sonst finde ich den Vergleich etwas weit hergeholt. Das haben die meisten Datenbanken damals auch nicht. >>>> *Kooperatives Multitasking ist einfach nur Schrott.* Ich habe mich >>>> neulich mit einem Mitt-Fünziger unterhalten, der asyncio in seinem >>>> neusten Projekt einsetzt, und habe ihn gefragt, wie er es findet und >>>> ob es sich irgendwie zu kooperativen Multitasking aus >>>> Mainframe-Zeiten (was bekanntlich aus der Mode gekommen ist) >>>> unterscheidet. >>>> >>>> Er sagte folgendes: >>>>> naaa it’s the same thing .. like a loop u know .. marketing .. blah >>>>> blah .. some technology went out from window .. and back from doors >>>>> .. like something new *we call that progress* .. but is something >>>>> like reinvent the wheel for sell something ;) ppl need “new” words, >>>>> “new” languages .. to feel young :-) >>> >>> “”” Alter Mann erklaert Technologie, die nach seiner eigenen >>> Sturm-und-Drang-Phase entwickelt wurde, fuer ueberfluessig. >> >> Eher umgekehrt. Alter Mann erkennt, dass die Technologie, die da als >> "neu entwickelt" angepriesen wird, schon in seiner Jugend nicht mehr neu >> war. > > Wenn der alte Mann kooperatives Multitasking mit asynchroner > Programmierung auf einem ansonsten immer noch präemptiven OS > gleichsetzt, bleibe ich da eher bei meiner Sichtweise... Du kannst natürlich jede Dir genehme Sichtweise auf Leute haben, die Du gar nicht kennst (ich kenne den alten Mann, von dem da die Rede ist, auch nicht). Du könntest aber auch annehmen, dass jemand, der ein bisschen Erfahrung hat, in der Lage ist, Ähnlichkeiten zwischen verschiedenen Systemen, die er im Lauf der Zeit kennengelernt hat, zu erkennen. hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

2 1

asyncio für Python2.7
by Thomas Güttler 19 Jan '18

19 Jan '18

Hallo, derzeit wird in meinem aktuellen Kontext Python2.7 verwendet, und das wird sich vor 2019 vermutlich nicht ändern. Prinzipiell gefällt mir asyncio nicht schlecht, aber 2.7 ... Es scheint einen Backport zu geben: https://pypi.python.org/pypi/trollius Das letzte Release ist von Anfang 2016. Also bald zwei Jahre alt. Es scheint also nicht wirklich aktiv zu sein. Was denkt ihr dazu? Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines

3 2

Re: [Python-de] select.epoll() vs async framework (PostgreSQL)
by Peter J. Holzer 19 Jan '18

19 Jan '18

On 2018-01-17 18:36, Sven R. Kunze <srkunze(a)mail.de> wrote: > On 16.01.2018 19:55, Stefan Behnel wrote: >> AsyncIO wurde exakt und einzig und allein aus dem Grund geschrieben, >> dass es bereits zu viele davon gab, die alle nicht miteinander >> kompatibel waren. Wenn Thomas also jetzt darüber nachdenkt, sein >> handgedrechseltes select() noch weiter zu einem solchen auszubauen, >> dann nehme ich das als Anreiz, auf die vergleichbaren Fehler anderer >> hinzuweisen, aus denen bereits nachhaltig Lehren gezogen wurden. > > select ist doch eine Standardfunktion. Was ist daran handgedrechselt? > Meinst du die Schleife in der das select vorkommt? Eher die State-Machine, die Du brauchst, um zu wissen, was Du mit welchem Filedescriptor als nächstes machen sollst. hp -- _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung: |_|_) | | Man feilt solange an seinen Text um, bis | | | hjp(a)hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

1 0

Python-Schulung in Hamburg?
by Thomas Weiner 18 Jan '18

18 Jan '18

Hallo zusammen, Kolleg*innen von mir sind auf der Suche nach einem Anbieter für eine zwei- bis dreitägige Python-Schulung in Hamburg für Einsteiger. Die Eckdaten: - Ort: gerne vor Ort in Harburg, sonst auch an einem anderen Veranstaltungsort in Hamburg - Zielgruppe: Personen, die mit skriptbasierter Bearbeitung von Daten (Postgresql oder STATA) Erfahrung haben, aber Anfänger hinsichtlich Programmiersprachen sind - Inhalt (Vorschlag): - Überblick über die Funktionsweise von Python, - Durchgehen exemplarischer Anwendungsfälle - Lesen und verstehen von Skripten - erste eigene Skripte schreiben - Besonderes Interesse hinsichtlich der Verwendung im Zusammenhang mit Datenbanken (Postgres) und Geoinformationssystemen (Qgis). - Dauer: 2-3 Tage - 5-6 Personen Budget: ist vorhanden. Kann von euch jemand weiterhelfen? Konkrete Hinweise / Angebote gerne direkt an mich. Merci und viele Grüße, Thomas Weiner

1 0

python-de January 2018