Mailman 3 September 2012 - 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

Python unconference in Hamburg Mai 2013?
by Hinrich Sager 21 Mar '13

21 Mar '13

Wir vom boot e.V. erwägen, eine Python unconference in Hamburg zu organisieren. Um das Interesse auszuloten hier ein poll: http://doodle.com/6428g4m7n28cvvyq

5 10

String Interpolation in ElementTree implementieren
by Florian Lindner 08 Oct '12

08 Oct '12

Hallo, ich will erreichen, dass man in XML Ersetzungen einbetten kann, also: <root filesystem="{filesystem}"> {files} </root> ich habe ein Dictionary repl = {"filesystem" : "btrfs", "files" : "whatever"} und würde das beim parsen des XML einfach mitgeben und bekomme dann die Strings schon fertig eingesetzt zurück. Ersetzt werden sollen Attribute und Text. Hier fängt das Problem an. Als XML-API benutze ich ElementTree. Das einfachste wäre wohl, wenn der ElementTree benutzende Code sich selber drum kümmert: str = interpolate(node.attrib["filesystem"], repl). Oder halt einfach direkt .format aufruft. Mir wäre es aber am liebsten, wenn ich das weitgehend transparent einbinden könnte. Wenn ich nun von xml.etree.ElementTree.ElementTree ableite und die Methoden text und attrib überschreibe, ok... Nur müsste ich wohl auch sämtliche Funktionen modifizieren, die ElementTrees zurückgeben (damit sie meine Kindklasse zurückgeben) und das wäre dann wohl doch recht viel Aufwand. Wie macht man sowas am geschicktesten? Danke, Florian

5 7

Threads in Django
by Michael Ziegler 30 Sep '12

30 Sep '12

Hallo, ich hab mir als ein Bastler-Projekt einen Daemon gebaut, welcher aus seiner Config einen Haufen Objekte baut, diese zur Laufzeit mit Zustandsinformationen anreichert und den ganzen Kram auf dem DBus exportiert. Das ganze garniert mit einer Client-Library, welche ein Fremdprozess benutzen kann, um die gleichen Objekte mit möglichst den gleichen Informationen drin zu haben. Ich möchte jetzt eine Django-Webapp bauen, die diesen Zustand bunt zum Klicken darstellen kann. Dazu instanziere ich meine Client-Library und lese aus dem resultierenden Objekthaufen gemütlich alle Infos raus die ich dazu brauche. So weit, so gut. Spannend wird es bei der Frage, wie ich mit meinem Objekthaufen auf dem neuesten Stand bleibe. Die einfachste Methode ist natürlich, in der View für jeden Request einen neuen Objekthaufen zu erzeugen, in dem dann der aktuelle Stand drinsteht. Das klingt aber verschwenderisch und nach ekligem Design. Da das ganze ein Bastler-Projekt ohne Deadlines ist, kann ich es mir leisten, sowas nicht zu wollen. ;) Schöner finde ich, einen Thread zu erzeugen, der im Hintergrund auf DBus-Signale von meinem Daemon wartet und dann den Objekthaufen entsprechend anpasst. Dann hab ich nicht nur ständig aktuelle Informationen, ich spare mir auch die Latenz einer Abfrage über den DBus. Und wenn mein Daemon grade mal neu gestartet wird (crashen würde der nie!) steht die Web-Oberfläche trotzdem noch zur Verfügung, sie ist halt nur erstmal outdated. Den Thread zu erzeugen ist an sich auch kein Problem, aber wie werde ich ihn wieder sauber los, wenn "./manage.py runserver" ein ^c empfängt oder der WSGI-Daemon-Prozess vom Apache gekillt wird? Wird der Prozess überhaupt gekillt, oder fällt nur das WSGI-Script aus dem Scope und wird Garbage-collected? Ich habe in der WSGI-Doku[0] einen Hinweis auf atexit gefunden, und daraufhin mal probiert in meiner views.py einen Thread zu erzeugen. Dieser schreibt alle zwei Sekunden ein "Hallo" in die Konsole, bis er von irgendwem das Signal bekommt, damit aufzuhören. Wenn ich nun "./manage.py runserver" ausführe, sehe ich auch meine Hallos. Leider wird der Thread nach einem ^c nicht beendet, sondern läuft im Hintergrund weiter, bis ich den Prozess hart kille. Ich vermute dass der Thread hier verhindert dass atexit aufgerufen wird, weil der Prozess sich ja bei ^c nicht mehr beendet (sondern nur der Vordergrund-Thread). Wie geht das richtig? Viele Grüße und einen schönen Sonntag, Michael [0] http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode#Cleanup_On_Pro… -- Öffentlicher Schlüssel: 48F81543 - Michael Ziegler (Svedrin) Wo kämen wir denn da hin, wenn jeder nur fragte "Wo kämen wir denn da hin?", aber niemand ginge, um zu sehen, wohin wir kämen, wenn wir gingen? (Autor unbekannt)

2 2

Re: [Python-de] threads
by wg 29 Sep '12

29 Sep '12

On 25.09.2012 14:09, Christian Heimes wrote: > Am 25.09.2012 13:52, schrieb Diez Roggisch: >> Angehalten oder abgebrochen? Wenn letzteres, dann vielleicht doch besser >> über das Modul multiprocessing gehen + einfach den Subprozess töten. >> >> Und in Antwort auf deine andere Mail: nein, ich habe da keinen >> Beispielcode, und ich zweifele auch ein bisschen an der Durchführbarkeit. >> >> Eine Garantie für dieses Verhalten kann es letztlich auch mit dem GIL >> nicht geben, denn wie gesagt - wenn du dich da in einem C-Callstack >> befindest, dann hat das GIL da keinen Einfluss mehr. > > Diez hat absolut recht. > > Das gewünschte Verhalten ist mit threads nicht umsetzbar. Wenn du einen > Programmablauf zu jeder Zeit, sofort und zuverlässig beenden willst, > dann musst du einen weiteren Prozess verwenden. Nicht mal > pthread_cancel() oder pthread_kill() garantieren ein verlässliches und > zeitnahes beenden eines Threads. Mal abgesehen davon, dass bei > pthread_kill() dein Programm in einem undefinierten Zustand hängen wird. > > Dein Problem ist unabhängig von Python und ist auch mit reinem C-Code > nicht umsetzbar. Selbst bei Prozessen geht es mit SIGTERM, SIGKILL, > SIGSTOP / SIGCONT nicht zuverlässig synchron. > > Christian > > Naja, SuspendThread(thread) und ResumeThread(thread) macht in C/C++ das was ich will. Detto Siganlhandling. Nur gibt's unter Windows kein SIGSTOP, SIGCONT, SIGUSER1/2 etc; das geht nur auf Nixen. Also wird's wohl eine C-nahe Lösung werden. Danke für deinen Kommentar. Wolf

4 4

Python User Group Hannover Treffen
by Python User Group Hannover 28 Sep '12

28 Sep '12

Hallo zusammen, Die Python User Group Hannover-Hildesheim trifft sich Mitte Oktober wieder. Treffpunkt ist 31157 Sarstedt. Bitte tragt euch bei Doodle ein, wann ihr Zeit habt. Hier der Link: http://doodle.com/csftr28kgxfr8ve5#table Der endgültige Termin richtet sich dann nach den Tag, an dem es am meisten Überschneidungen gibt und wird per Mail bekannt gegeben. Wie immer ist der Gruppensprecher über diese Mailadresse zu erreichen (group(a)python-hannover.de). Viele Grüße Daniel Milbrandt -- Python User Group Hannover http://www.python-hannover.de

1 0

Re: [Python-de] threads
by wg 26 Sep '12

26 Sep '12

On 25.09.2012 22:03, "Martin v. Löwis" wrote: > Am 25.09.2012 17:39, schrieb wg: >>> Dein Problem ist unabhängig von Python und ist auch mit reinem C-Code >>> nicht umsetzbar. Selbst bei Prozessen geht es mit SIGTERM, SIGKILL, >>> SIGSTOP / SIGCONT nicht zuverlässig synchron. >>> >>> Christian >>> >>> >> Naja, SuspendThread(thread) und ResumeThread(thread) macht in C/C++ das >> was ich will. > > Es kann sein, dass es das macht, was Du willst - aber nicht, was Du > gesagt hast dass Du willst. > > SuspendThread garantiert nicht, dass der Zielthread *sofort* angehalten > wird. Es kann schon sein, dass er u.U. noch etliche Takte weiterrechnet, > bevor er angehalten wird. Vielmehr wird für den Zielthread lediglich > der Suspend-APC beantragt, der dann "demnächst" den Thread auch anhält. > > Ciao, > Martin > Ja, Martin, das ist klar. Wie schon in einem vorigen Posting erwähnt, ist der Begriff *sofort* von mir missverständlich verwendet worden. Es genügt vollauf, wenn der Stop ein paar Takte später erfolgt. Danke, Wolf

1 0

Re: [Python-de] threads
by wg 25 Sep '12

25 Sep '12

On 25.09.2012 11:08, Diez Roggisch wrote: > On 9/25/12 9:34 AM, "wg" <wg1(a)gmx.net> wrote: > >> On 24.09.2012 22:08, Vinzent Hoefler wrote: >>> wg wrote: >>> >>>> gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2 >>>> aktiv wird? >>> >>> Mit einem entsprechenden Lock, ja. >>> >>> >>> Vinzent. >>> >> OK, dazu muss ich thread 2 über lock oder queue steuern. >> Da ich aber thread 2 an *beliebiger* Stelle von *thread 1* aus anhalten >> will, kommt ich das so nicht machen. > > Beliebig gibt's nicht. Wenn der Thread im C-Callstack steht, wird der > ausgeführt. > > > >> >> Gibt's eine Möglichkeit, den GIL (von python aus) zu beeinflussen? >> Und zwar in der Form, daß thread 1 den GIL-State für sich beansprucht. >> Das C-API hat so eine Funktion: >> PyGILState_STATE PyGILState_Ensure() > > Nichts offizielles, das ist bestenfalls ein hack. Du kannst natürlich > versuchen, über ctypes an's GIL zu kommen. Hast dafür evtl. Hinweise/Links wie sowas gehen könnte? > > Und muss diese Salami-Taktik bei der Problembeschreibung sein? Das > beständige Glaskugelwetzen ist anstrengendŠ > > Diez > > Ja, hast recht (Glaskugel?wetzen?); ich wolle nur niemanden mit folgender Aufgabenstellung langweilen: Thread 1 mit GUI, Daten werden von thread 2 via queue geliefert. Thread 1 kann mit Button (oder Key) thread 2 *an belibeiger* Stelle pausieren lassen. Wird wohl ein C-framework dafür notwendig sein. Wolf

4 5

Re: [Python-de] threads
by wg 25 Sep '12

25 Sep '12

On 25.09.2012 13:52, Diez Roggisch wrote: > On 9/25/12 1:08 PM, "wg" <wg1(a)gmx.net> wrote: > >> On 25.09.2012 12:23, Vinzent Hoefler wrote: >>> wg wrote: >>> >>>> ich wolle nur niemanden mit folgender Aufgabenstellung langweilen: >>>> Thread 1 mit GUI, Daten werden von thread 2 via queue geliefert. >>>> Thread 1 kann mit Button (oder Key) thread 2 *an belibeiger* Stelle >>>> pausieren lassen. >>> >>> Jetzt muß ich doch mal blöd fragen: Wozu? Wenn die Queue voll ist, >>> wird Thread 2 doch ohnehin angehalten, weil er nix mehr schreiben kann. >>> Damit wäre es von Thread 1 aus am einfachsten, die Queue nicht mehr >>> auszulesen, um Thread 2 schlafen zu legen. >>> >>> Notfalls kann man auch an der Queue-Semantik ein wenig rumschrauben >>> und dort etwas wie "jetzt keine Nachrichten mehr akzeptieren, auch >>> wenn Queue noch nicht voll ist" implementieren. >>> >>> >>> Vinzent. >>> >> Das ist eine realtime Videoüberwachung und der workerthread 2 führt >> Aktionen durch, die u.U. vom GUI aus *sofort* angehalten werden sollen. >> Der thread 2 ist tief verschachtelt, eine Abfrage 'kann i weitermachen' >> müsste an vielen Stellen eingebaut werden. > > Angehalten oder abgebrochen? Wenn letzteres, dann vielleicht doch besser > über das Modul multiprocessing gehen + einfach den Subprozess töten. > > Und in Antwort auf deine andere Mail: nein, ich habe da keinen > Beispielcode, und ich zweifele auch ein bisschen an der Durchführbarkeit. > > Eine Garantie für dieses Verhalten kann es letztlich auch mit dem GIL > nicht geben, denn wie gesagt - wenn du dich da in einem C-Callstack > befindest, dann hat das GIL da keinen Einfluss mehr. > > Da ist Prozess töten wirklich die bessere Alternative. > > Diez > > thread stop/run ist gefordert, auf Interpreterlevel. Eine Variante mit python: win32process.SuspendThread(thread) win32process.ResumeThread(thread) Nur daß so unter bestimmten Umständen das GUI hängenbleibt. Daher ist eine C/Python-Anwendung wahrscheinlich der beste Weg. Oder aber man nehme anstelle von threads Prozesse, wie du vorschlägst. Danke für deine Kommentare, Wolf

1 0

threads
by wg 25 Sep '12

25 Sep '12

Hi Leute, gibts eine Möglichkeit, dass thread 1 verhindern kann dass thread 2 aktiv wird? Im thread selber kann ja die Kontrolle abgeben werden mit einen I/O, sleep u.ä. Dake für Tipps, wg

3 3