Mailman 3 January 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

Problem mit fork() in der C-API
by ole-usenet-spam＠gmx.net 01 Feb '12

01 Feb '12

Hallo Gruppe, ich habe einen C-Code an Python mit der C-API angebunden, der u.a. einen fork() mit einem exit() macht. Der C-Code sieht etwa so aus (library und Code zusammengeworfen): -------------------8<------------------------------ #include <unistd.h> #include <Python.h> static PyObject *bar(PyObject *self) { pid_t childpid = fork(); if (childpid == 0) exit(0); sleep(1); return Py_BuildValue("s", "Ready."); } static PyMethodDef foo_methods[] = { {"bar", (PyCFunction)bar, METH_NOARGS, "Bla"}, {NULL, NULL, 0, NULL} }; PyMODINIT_FUNC initfoo(void) { Py_InitModule("foo", foo_methods); } -------------------8<------------------------------ Das Beispielmodul kann man mit einem trivialen setup.py einbinden: -------------------8<------------------------------ from setuptools import setup, Extension module1 = Extension('foo', sources = [foo.c']) setup (name = 'foo', packages = ['foo'], ext_modules = [module1]) -------------------8<------------------------------ Wenn ich damit folgendes mache: -------------------8<------------------------------ a = open("a.dat", "w"); for i in range(10): foo.bar() a.write(" %i" % i) a.close() -------------------8<------------------------------ dann sieht "a.dat" so aus: -------------------8<------------------------------ 0 0 1 0 1 2 0 1 2 3 0 1 2 3 4 0 1 2 3 4 5 0 1 2 [...] -------------------8<------------------------------ Offenbar versucht jedes Kindprogramm den Cache zu leeren. Ein Ersetzen von exit() im C-Code durch _exit() ändert daran jedoch auch nichts. Eine analoge Funktion die man direkt aus C heraus aufruft, zeigt dieses Verhalten nicht, daher scheint es sich um ein CPython-Spezifikum zu handeln. Warum ist das so und wie kann ich das verhindern? Viele Grüße Ole

3 3

Re: [Python-de] Laden einer *.dll
by Bernd Waterkamp 31 Jan '12

31 Jan '12

Hartmut Goebel schrieb: > Kennst Du auch ein Windows-Tool, mit dem man sehen kann, welche Dateien > geladen werden? Unter Linux würde ich dafür `strace -e trace=open` nehmen. Die "Sysinternals Suite" hat dafür einige Werkzeuge, zum Beispiel ListDLLs und den Process Explorer. Letzteren solltest du dir mal anschauen: http://technet.microsoft.com/de-de/sysinternals/bb896653 Grüße, Bernd

1 0

Re: [Python-de] Problem mit fork() in der C-API
by ole-usenet-spam＠gmx.net 31 Jan '12

31 Jan '12

Christian Heimes <lists(a)cheimes.de> writes: > Wenn du selbst einen Fork machst, musst du auch die passenden Hooks > verwenden. [..] > http://docs.python.org/c-api/sys.html#PyOS_AfterFork Zitat: | Function to update some internal state after a process fork; this | should be called in the new process | if the Python interpreter will continue to be used. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | If a new executable is loaded into the new process, this function does | not need to be called. Mein Code: pid_t childpid = fork(); if (childpid == 0) exit(0); Ich sehe nicht so direkt, warum der Python-Interpreter "will continue to be used" im neuen Thread ist. > Das ist schon mal ein Bug in deinem Code. Warum?

1 0

Re: [Python-de] Laden einer *.dll
by jsapen＠googlemail.com 31 Jan '12

31 Jan '12

Hallo, vielen Dank für die Tipps, habe jetzt mal wieder ein wenig rumprobiert und bin leider noch nicht weiter. Auch wenn ich mit pyinstaller die *.exe bauen lassen, funktioniert das Programm nur auf meinem Rechner. Es gibt Funktionen in der *.dll, für die brauche ich keine Kommunikation mit der Messnabe, wenn ich diese Aufrufe erhalte ich auch die Richtige Rückgabewerte. Somit ist meine Vermutung das es "nur" noch an dem Kommunikationsaufbau zwischen Programm und Messnabe liegt. Gibt es eine Möglichkeit herauszufinden, was auf meinem Rechner von dem Programm genutzt wird, dass es funktioniert? Vielleicht finde ich dann ja raus warum das auf anderen Rechnern einfach nicht klappen will. Oder gibt es vielleicht eine andere Möglichkeit statt ctypes, sofern es daran liegen sollte? Viele Grüße Janina

4 4

Re: [Python-de] Laden einer *.dll
by Michael Meyer 31 Jan '12

31 Jan '12

*** Hartmut Goebel <h.goebel(a)goebel-consult.de> wrote: > Am 27.01.2012 14:40, schrieb Massa, Harald Armin: > >Findest Du als "Dependency Walker" unter http://www.dependencywalker.com/ > > Danke für den Tipp :-) Damit können wir bei PyInstaller vielleicht > die eine oder andere Bug-Anfrage abstellen. > > Kennst Du auch ein Windows-Tool, mit dem man sehen kann, welche > Dateien geladen werden? Unter Linux würde ich dafür `strace -e > trace=open` nehmen. http://www.softpedia.com/get/Programming/Debuggers-Decompilers-Dissasembler… Ich kenne das aber nicht, Windows ist nicht soooo mein Ding. ;) HTH Micha

2 1

Problem mit regex
by Helmut Blass 31 Jan '12

31 Jan '12

Hallo NG; bin gerade dabei, mich in Python einzuarbeiten und versuche mich mit regulaeren Ausdruecken: import re regex = re.compile("string") result = regex.search("demostring") result.group() laut meinem Lehrbuch muesste da doch ein Treffer ausgegeben werden. Tut es aber nicht ;-(( Fehlermeldung gibt es auch nicht..... Was ist hier falsch? (Version 2.7.2) thanx for your help, Helmut

3 2

ANN: pyftpdlib 0.7.0 released
by g.rodola＠gmail.com 25 Jan '12

25 Jan '12

Hi, I'm pleased to announce release 0.7.0 of Python FTP Server library (pyftpdlib). http://code.google.com/p/pyftpdlib/ === About === Python FTP server library provides an high-level portable interface to easily write asynchronous FTP/S servers with Python. pyftpdlib is currently the most complete RFC-959 FTP server implementation available for Python programming language. === sendfile() === sendfile(2) system call usage has finally been introduced. sendfile(2) provides a "zero-copy" way of copying data from one file descriptor to another (a socket). The phrase "zero-copy" refers to the fact that all of the copying of data between the two descriptors is done entirely by the kernel, with no copying of data into userspace buffers, resuting in file transfers (RETR, hence from server to client) being from 2x to 3x faster. A simple benchmark: pyftpdlib 0.6.0: 693.41 MB/sec pyftpdlib 0.7.0: 1694.14 MB/sec proftpd 1.3.4rc2: 1313.77 MB/sec vsftpd 2.3.2: 1505.18 MB/sec In order to use sendfile(2) you'll have to install pysendfile module first (UNIX only): http://code.google.com/p/pysendfile/ === Faster scheduler === The internal scheduler, governed by CallLater and CallEvery classes, has been rewritten from scratch and it is an order of magnitue faster, especially for operations like cancel() which are involved when clients are disconnected (hence invoked very often). Some benchmarks: schedule: +0.5x reschedule: +1.7x cancel: +477x (with 1 milion scheduled functions) run: +8x Also, a single scheduled function now consumes 1/3 of the memory thanks to __slots__ usage. For further details see: http://code.google.com/p/pyftpdlib/issues/detail?id=189 === SITE CHMOD === This new version supports SITE CHMOD command, meaning the client is now able to change file mode bits by issuing "SITE CHMOD path mode" command. The authorizer now accepts a new "M" permission bit, which, when specified, enables SITE CHMOD usage: >>> authorizer = DummyAuthorizer() >>> authorizer.add_user('user', 'password', '/home/user', perm='elradfmwM') === Other improvements === * on_failed_login() callback: this is called when user provides wrong credentials. * CallEvery class: same as CallLater, but keeps calling a function every X seconds. * A benchmark script: http://code.google.com/p/pyftpdlib/source/browse/trunk/test/bench.py * Anti flood demo script: http://pyftpdlib.googlecode.com/svn/trunk/demo/anti_flood_ftpd.py A complete list of changes including enhancements and bug fixes is available here: http://code.google.com/p/pyftpdlib/wiki/ReleaseNotes07 === More links === * Source tarball: http://pyftpdlib.googlecode.com/files/pyftpdlib-0.7.0.tar.gz * Online docs: http://code.google.com/p/pyftpdlib/wiki/Tutorial * FAQs: http://code.google.com/p/pyftpdlib/wiki/FAQ * RFCs compliance paper: http://code.google.com/p/pyftpdlib/wiki/RFCsCompliance * Issue tracker: http://code.google.com/p/pyftpdlib/issues/list If you think pyftpdlib is worth a donation you can do so by going here: http://code.google.com/p/pyftpdlib/wiki/Donate Thanks, --- Giampaolo Rodola' http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ http://code.google.com/p/pysendfile/

1 0

Laden einer *.dll
by jsapen＠googlemail.com 25 Jan '12

25 Jan '12

Hallo, ich nutze ctypes um eine dll zu laden, welche in c++ geschrieben ist. Diese *.dll enthält Methoden mit denen es Möglich ist eine Kommunikation zur Messnabe via Bluetooth aufzubauen und um die Werte zu empfangen welche von der Messnabe gesendet werden. Der Aufruf der *.dll erfolgt mit windll.loadlibrary(...) Rufe ich die Methoden aus der *.dll auf, so erhalte ich entweder: 0 -->Ok -1 --> Error Nu habe ich folgendes Problem, nachdem ich mit py2exe die *.exe gebaut habe: - Auf meinem Rechner(Vista) mit dem ich Programmiere, funktioniert das alles wunderbar und ohne Probleme - auf einem XP Rechner funktioniert das Programm mal und mal nicht, das Phänomen tritt zufällig auf - auf einem Vista Rechner ist es nicht Möglich, die Kommunikation zwischen Messnabe und Programm aufzubauen. Das Programm erkennt das auf einer bestimmten Com Stelle etwas angeschlossen ist (versucht sich zu verbinden) aber nach kurzer Zeit bekomme ich die Meldung dass der Verbindungsaufbau nicht funktioniert hat (Die Meldung stammt aus meinem Programm) Die *.dll welche ich aufrufe ist auch auf den Testrechnern vorhanden, das war meine erste Vermutung. Mittlerweile habe ich keine Idee mehr woran es liegen kann, da ich keine Fehlermeldung bekomme und so stochere ich im nix rum und hofft das richtige zu finden, was nicht wirklich effektiv ist. Hat vielleicht jemand eine Idee woran es liegen kann, dass keine Kommunikation aufgebaut werden kann, bzw. das die Methoden aus der *.dll immer -1 zurückliefert? Viele Grüße JS

3 2

FYI: 3 GiB in python.exe
by Thomas Rachel 24 Jan '12

24 Jan '12

Hallo, ich habe gerade etwas RAM zu meinem Arbeits-PC hinzugefügt und hätte gerne, daß Python (@Win) es nutzen kann. Der /3GB-Schalter in boot.ini war bereits gesetzt, dennoch konnte ich nur 2 GB nutzen. Daher habe ich python.exe mit dem imagecfg.exe-Programm von http://blog.schose.net/index.php/archives/207 bearbeitet. Jetzt gehts. Dies ist nur FYI, falls jemand dasselbe tun möchte. Ohne Garantie, daß nicht irgenwelche Nebenwirkungen auftreten! HTH jemandem, Thomas

1 0