Mailman 3 April 2012 - python-de

Re: [Python-de] Lesbarkeit
by Dinu Gherman April 5, 2012

April 5, 2012

"Stefan Ram" <ram(a)zedat.fu-berlin.de>: > Ich sah zufällig gerade > > http://garr.dl.sourceforge.net/project/malclassifier.adobe/AdobeMalwareClas… > http://sourceforge.net/projects/malclassifier.adobe/files/AdobeMalwareClass… > > und fragte mich: Verschachtelte if-Anweisungen in Python - der Gipfel > der Lesbarkeit von Quelltext? Bei erstaunlichen 16 Stufen maximaler Einrückung wohl eher nicht. Ein schöner Test übrigens für mein schon etwas betagtes "fileinfo": $ fileinfo -a mil AdobeMalwareClassifier.py 16 AdobeMalwareClassifier.py Aber auch eine schöne Übungsaufgabe dafür, wie man es besser machen kann. Gruß, Dinu

1 0

Abhängigkeit zwischen abgeleiteter Klasse und Basisklasse
by Wagner, Frank April 3, 2012

April 3, 2012

Hallo, kurze Beschreibung: Ich habe in wxPython eine Klasse z. B. "LogDiagramm" geschrieben die mir Messwerte aus einer Logdatei als Diagramm in einem Dialog darstellt. Zur Interaktion befindet sich auf dem Dialog nur ein "Close" Button und eine Checkbox um die automtische Skalierung ein bzw. abzuschalten. Zur Anzeige der aktuell gemessenen Messwerte habe ich eine zweite Klasse z. B. "OnlineDiagramm" geschrieben die von der Klasse "LogDiagramm" erbt. Da in der abgeleiteten Klasse die Daten und die Diagrammachsen etwas anders Dargestellt werden wurden lediglich die Funktionen drawAxis() und drawData() in dieser Klasse neu geschrieben. Somit nutzt eine Instanz der abgeleiteten Klasse alle Funktionen der Basisklasse bis eben auf diese Beiden. Auf eine dedizierte Initialisierung der abgeleiteten Klasse wurde ebenfalls verzichtet, womit die Funktion __init__() der Basisklasse ausgeführt wird. Nun zu meinem Problem: Bringe ich beide Diagrammdialoge zur Anzeige und klicke in die "Enable Autoscaling" Checkbox so wirkt sich die Aktion auf beide Diagramme aus. Dies wundert mich etwas da ich der Meinung war dass die entsprechenden Funktionen und Variablen nach den jeweiligen erzeugen einer Instanz eben nur in jener bekannt sind. Vermutlich mache ich hierbei einen Denkfehler bin aber noch nicht auf die entsprechende Lösung gestoßen. Ich würde mich sehr freuen wenn mir jemand einen Tipp geben könnte der mir auf die Sprünge hilft. Schon jetzt recht herzlichen Dank Viele Grüße Frank -- Bevor Sie diese E-Mail ausdrucken, überlegen Sie bitte, ob dies wirklich erforderlich ist. Please think before you print. -- WIKA Alexander Wiegand SE & Co. KG Alexander-Wiegand-Straße 30 - 63911 Klingenberg - Germany Kommanditgesellschaft: Sitz Klingenberg - Amtsgericht Aschaffenburg HRA 1819 Komplementärin: WIKA Verwaltungs SE & Co. KG - Sitz Klingenberg - Amtsgericht Aschaffenburg HRA 4685 Komplementärin: WIKA International SE - Sitz Klingenberg - Amtsgericht Aschaffenburg HRB 10505 Vorstand: Alexander Wiegand Vorsitzender des Aufsichtsrats: Dr. Max Egli Telefon: (09372) 132-0 Internet: www.wika.com -- The information contained in this E-Mail and any attached files are strictly confidential and may be subject to legal privilege. If you are not the intended recipient, his representative or the person responsible for delivering the message to the intended recipient, be advised that you have received this message in error and that any dissemination, copying or use of this message or attachment is strictly forbidden, as is the disclosure of the information therein. If you have received this E-Mail in error, please notify us immediately by E-Mail or telephone and delete this message and all its attachments subsequently. All reasonable precautions have been taken to ensure no viruses are present in this E-Mail.

3 6

Re: [Python-de] Extension
by Philipp Kraus April 2, 2012

April 2, 2012

On 2012-03-27 11:35:13 +0200, Christian Theune said: > On 03/27/2012 11:19 AM, Stefan Behnel wrote: >> Stefan Behnel, 27.03.2012 10:54: >>> Philipp Kraus, 23.03.2012 16:30: >>>> Wenn ich das dann richtig verstehe, würde mir der Generator aus meiener CPP >>>> Implementation der Klasse entsprechenden Pythoncode erzeugen >>> >>> Grundsätzlich erstmal ja >> >> Äh, hopsa - zu schnell geantwortet. "Python-Code" im Sinne von "Code für >> CPython" (oder andere Python-Implementierungen), nicht im Sinne von "Python >> Source-Code". >> >> Der generierte Code ist in deinem Fall immer C++ (wenn auch wahrscheinlich >> mit hohem C-Anteil). > > Und noch eigentlicher erzeugt er doch nur Glue-Code, der den > Objekt-Code der entsprechenden Library instrumentiert und dieser > Glue-Code ist für Python sichtbar. Die Original-Library wird ja dadurch > nicht nach Python portiert sondern für Python nutzbar. Erst einmal vielen Dank an alle. Ich habe mir jetzt noch mal Swig angeschaut und mit Java bzw JNI getestet, das funktioniert schon mal ganz gut und der erzeugte C Code ist jetzt auch nicht so schlimm. Swig erzeugt bei Java JNI C Code, wobei er eben die Adresse den C++ Objektes durchschleift und dann entsprechend damit arbeiten. Drumherum wird dann ein entsprechender Glue-Code erzeugt, mit dem ich dann unter Java arbeite. Ich hoffe mal, dass es bei Python genauso ist. Nur muss ich im Moment mich erst einmal in die Pakagestruktur einlesen und wie ich dann alles richtig organisieren. Es soll später ja ein portables Paket raus kommen mit prekompilierten Binaries bzw. Sources Codes zum selbst kompilieren. Zu den Algorithem: Es sind überwiegend Heuristiken und numerische Algorithmen, d.h. ich brauche nur eine Anbindung von Python, d.h. die Daten müssen durchgereicht werden. NumPy bietet zwar schon einige passende Algos fertig an, aber leider nicht alle. Außerdem möchte ich möglichst "einfache" Datentypen verwenden, d.h. Python soll mit simplen Typen und Listen arbeiten, die C/C++ Komponenten konvertieren dann die Daten passend und berechnen und liefern die Ergebnisse wieder in einfachen Typen / Listen nach Python. Danke Phil

1 0

Re: [Python-de] Extension
by Bernd Nawothnig April 1, 2012

April 1, 2012

On 2012-04-01, Stefan Behnel wrote: > Bernd Nawothnig, 01.04.2012 11:29: >> Es geht bei der ganzen Sache um einen rein numerischen Algorithmus, >> und da ist Python nun mal prinziell weniger gut für geeignet, weil >> dort alles Objekte sind, für _jede_ Berechnung also erst die >> "Nutzlast" aus dem Objekt geholt werden muss. Das ist zwar sehr schön >> für die Allroundverwendung (also mehr als 99% der real anfallenden >> Fälle, s.u.), aber ein klarer Nachteil bei einer so speziellen >> Geschichte. > > Deswegen benutzen die Number-Cruncher ja auch NumPy und/oder Cython (und > manchmal PyPy). Numpy habe ich mir natürlich angeschaut, und ich verwende auch ein numpy.array, um die Liste der Objekte effizient an das C Programm zu übergeben, aber für den Algorithmus würde das nicht viel bringen. Nebenbei wäre es deutlich unübersicher so, selbst unübersichtler als die C-Version, die natürlich ge-typedef-te structs verwendet, welche dann in der Anwendung nicht anders als Python Objekte ausschauen. Wie gesagt, die Übersichtlickeit der C-Version übertrifft meine Erwartungen und sie ist diesbezüglich nicht wesentlich schlechter als die Python-Version. In Numpy müsste ich alles wie in FORTRAN üblich auf Arrays runterbrechen, und das sieht, mit Verlaub, Scheiße aus ;-) >>>> , weil ich eben schneller werden will (was auch >>>> weit über alle Erwartungen geklappt hat ;-). Gerade die dauernden >>>> appends, bzw. auch Listcomprehensions, wie Du sie erwähntest (ich >>>> weiß, die sind sehr elegant und ich verwende die auch sehr gerne), >>>> holen sich jedes Mal Speicher vom Heap, der praktisch dann gleich >>>> wieder freigegeben werden kann >> >>> Äh, bitte wie? Warum sollten sie das denn tun? >> >> Wenn man Listen so erzeugt, wird jedesmal Speicher vom Heap geholt und >> der alte Speicherbereich kann freigegeben werden. > > Ah, du meinst das realloc(). Nein, da wird im Normallfall kein neuer > Speicherbereich alloziiert, sondern nur der alte erweitert. Entweder > macht das CPython selbst in seiner Heap-Verwaltung, indem es sich > schon vorab größere Bereiche greift, oder das Betriebsystem macht es, > notfalls indem es die virtuelle Speicherverwaltung umkonfiguriert. Danke, das wusste ich auch noch nicht. Ich hatte jetzt erwartet, dass stumpf neuer Speicher angefordert wird, und der Rest dem gc obliegt. Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche]

1 0

Re: [Python-de] Extension
by Bernd Nawothnig April 1, 2012

April 1, 2012

On 2012-03-28, Stefan Behnel wrote: >> Im reinen C-Teil verwende ich ja absichtlich _nicht_ die >> Python-Datenstrukturen > > Hatte ich auch so verstanden. Der Code oben (deiner und meiner) dient nur > der Konvertierung des Ergebnisses von C nach Python. > > Der Code, den Cython generiert, hat nur minimal höheren Aufwand als dein > handgeschriebener - er erzeugt die ursprüngliche Liste nämlich momentan > nicht mit der finalen Länge. Und das auch nur deshalb, weil ich immer noch > keine Zeit gefunden habe, die bekannte Länge der Ergebnisliste aus dem > Iterator durchzuschleifen. Sprich: mit ein bisschen zusätzlichem Aufwand > würde Cython sogar identischen Code generieren, ohne deinen ganzen C > Eiertanz oben. > > Allerdings würde es mich überraschen, wenn der Geschwindigkeitsunterschied > jetzt schon sehr auffällig wäre. Der eher meistens vernachlässigbar, weil > die Konvertierung der Listeneinträge normalerweise deutlich stärker zu > Buche schlägt als die Vergößerung der Liste, die meistens ohnehin von der > Speicherverwaltung aufgefangen wird. Es geht bei der ganzen Sache um einen rein numerischen Algorithmus, und da ist Python nun mal prinziell weniger gut für geeignet, weil dort alles Objekte sind, für _jede_ Berechnung also erst die "Nutzlast" aus dem Objekt geholt werden muss. Das ist zwar sehr schön für die Allroundverwendung (also mehr als 99% der real anfallenden Fälle, s.u.), aber ein klarer Nachteil bei einer so speziellen Geschichte. Und weil es eben reine Berechnungen sind, sieht der C-Code auch kaum weniger übersichtlich aus als in Python. Ich gewinne also durch Verwendung von Python an der Stelle nichts, es wird nur langsamer. Anders siehst das z.B. aus, wenn man mit Datenbanken arbeitet, und möchte SQL auf die Applikationssprache abbilden. Ich verwende z.Z. auf der Arbeit Java und da ist das schon ein ganz schöner Eiertanz, wenn man Java double oder int einfach nur in ein Dictionary einfügen möchte oder etwa statt int SQL NULL bekommt. Alleine die Menge der try/catch/throws bläht den Code gegenüber Python ebenso gewaltig wie vollkommen unnötig auf. In Python (etwa zusammen mit psycopg2) erhält man dann ein sauberes und eindeutiges None und kein integer 0!. Alleine auf die Idee zu kommen, SQL NULL::int auf 0 ist mappen, ist krank und hochgradig fehlerträchtig. Und selbstverständlich kann ich in Python auch Ganzzahlen in ein Dictionary einfügen - ohne erst eine Wrapper-Klasse dafür anlegen zu müssen. >>, weil ich eben schneller werden will (was auch >> weit über alle Erwartungen geklappt hat ;-). Gerade die dauernden >> appends, bzw. auch Listcomprehensions, wie Du sie erwähntest (ich >> weiß, die sind sehr elegant und ich verwende die auch sehr gerne), >> holen sich jedes Mal Speicher vom Heap, der praktisch dann gleich >> wieder freigegeben werden kann > Äh, bitte wie? Warum sollten sie das denn tun? Wenn man Listen so erzeugt, wird jedesmal Speicher vom Heap geholt und der alte Speicherbereich kann freigegeben werden. >> während der mir sehr wohl bekannte >> wirkliche Speicherverbrauch dieses Algorithmus _sehr_ überschaubar >> ist. Entsprechend dramatisch war dann auch der Speedup (mehr als >> Faktor 1000). > > Aber nur gegenüber CPython, richtig? Ja. Und ich muss auch sagen, dass ich bei der Umstellung diverse Schwächen des Python-Codes erkannt, und dann natürlich in C entsprechend geändert habe. So wurden z.B. in in der Pythonversion zwecks Abstandsberechnungen in der inneren Schleife jeweils Quadratwurzeln gezogen. Allerdings fiel mir jetzt auf, dass ich ja ebenso die Quadrate der Abstände vergleichen kann (es interessiert hier nur ein <=, kein ==), die eh einen Schritt vorher anfallen. Wenn man das jetzt in Python ebenfalls umstellen würde, wozu ich aber nun keine Lust habe, sähe das Ergebnis mit Sicherheit nicht ganz so schlecht für Python aus. [...] > Schau in die Doku (wie Dietmar es für dich getan hat). Unnötig zu sagen, > dass Cython dir diese Details abnimmt. Ich werde mir Cython wohl ebenfalls mal anschauen müssen :) Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche]

2 1

Re: [Python-de] Extension
by Bernd Nawothnig April 1, 2012

April 1, 2012

On 2012-03-27, Stefan Behnel wrote: > Bernd Nawothnig, 27.03.2012 17:03: >> Ein Pythonprogramm ruft eine in C geschriebene Extension mit einem >> Parameter auf, der aus einer in ein numpy.array konvertierten >> Python-Liste von Objekten besteht. Das C-Programm nutzt dazu einen >> Zeiger auf dieses nun eng gepackte Array von Zeigern und wählt durch >> einen geeigneten Algorithmus aus dieser Objektmenge einige aus, die >> nun in eine Python-Liste von Python-Listen von Objekten gekapselt >> zurückgegeben werden. Freigegeben oder verändert wird keines der beim >> Aufruf der Extension übergebenen Objekte. Die Python-Ergebnisliste >> wird in C so konstruiert: >> ... >> PyObject *r = PyList_New(0); >> ... >> static PyObject *VLP_asPyList(VectorlistP *vl) >> { >> PyObject *result = PyList_New(vl->length); >> int i; >> >> for (i=0; i<vl->length; i++) >> PyList_SetItem(result, i, Py_BuildValue("O", vl->list[i]->anomaly)); >> // ^^^^^^^^^^^^^^^^^^^^ >> // Zeiger auf eins der ursprünglichen Objekte >> return result; >> } >> ... >> PyList_Append(r, VLP_asPyList(&bestResult)); > > Hier war ein "extend()" gemeint, oder? Nein, ein PyList_Append, also entsprechend einem python <list>.append(). >> return r; > > Zum Vergleich der (mangels umgebendem Code und Daten natürlich ungetestete) > äquivalente Code in Cython: > > return [ item.anomaly for item in bestResult.list[:bestResult.length] ] > > Finde ich hübscher und übersichtlicher. Im reinen C-Teil verwende ich ja absichtlich _nicht_ die Python-Datenstrukturen, weil ich eben schneller werden will (was auch weit über alle Erwartungen geklappt hat ;-). Gerade die dauernden appends, bzw. auch Listcomprehensions, wie Du sie erwähntest (ich weiß, die sind sehr elegant und ich verwende die auch sehr gerne), holen sich jedes Mal Speicher vom Heap, der praktisch dann gleich wieder freigegeben werden kann, während der mir sehr wohl bekannte wirkliche Speicherverbrauch dieses Algorithmus _sehr_ überschaubar ist. Entsprechend dramatisch war dann auch der Speedup (mehr als Faktor 1000). static PyObject *VLP_asPyList(VectorlistP *vl) macht aus meiner C-Variante ganz zum Schluss erst(!) Python, weil ich das Resultat ja schließlich und letztendlich in Python haben möchte. Aber viel mehr würde mich interessieren, ob PyList_SetItem und PyList_Append automatisch den Referenzzähler der eingefügten, bzw. zugewiesenen Objekte erhöhen. Ich vermute es stark, und die Extension funktioniert auch problemlos, was aber ja keineswegs eine Garantie auf Korrektheit ist, weil der GC asynchron zuschlagen kann (und dann müssen die Referenzzähler korrekt gesetzt sein). Und deswegen wüsste ich es gerne explizit. Kann mir da einer was zu sagen? Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche]

3 4

Re: [Python-de] Extension
by Bernd Nawothnig April 1, 2012

April 1, 2012

On 2012-03-27, Stefan Behnel wrote: > SIP und SWIG sind automatische Wapper-Generatoren. Entweder, sie tun was du > willst - oder eben nicht. Und wenn nicht, dann wird's im besten Fall nur > irre kompliziert und im schlechtesten Fall kannst du das Tool wechseln. Wobei das händische Einbinden von C-Code in Python nun wirklich nicht schwer ist und durch die Python C-API gut unterstützt wird. Dazu vllt. auch gleich eine Frage. Gegeben sei folgende Ausgangssituation: Ein Pythonprogramm ruft eine in C geschriebene Extension mit einem Parameter auf, der aus einer in ein numpy.array konvertierten Python-Liste von Objekten besteht. Das C-Programm nutzt dazu einen Zeiger auf dieses nun eng gepackte Array von Zeigern und wählt durch einen geeigneten Algorithmus aus dieser Objektmenge einige aus, die nun in eine Python-Liste von Python-Listen von Objekten gekapselt zurückgegeben werden. Freigegeben oder verändert wird keines der beim Aufruf der Extension übergebenen Objekte. Die Python-Ergebnisliste wird in C so konstruiert: ... PyObject *r = PyList_New(0); ... static PyObject *VLP_asPyList(VectorlistP *vl) { PyObject *result = PyList_New(vl->length); int i; for (i=0; i<vl->length; i++) PyList_SetItem(result, i, Py_BuildValue("O", vl->list[i]->anomaly)); // ^^^^^^^^^^^^^^^^^^^^ // Zeiger auf eins der ursprünglichen Objekte return result; } ... PyList_Append(r, VLP_asPyList(&bestResult)); ... return r; Nun gibt es ja für jedes Python-Objekt einen Referenzzähler, der beim Konstruieren dieser Liste eigentlich inkrementiert werden müsste, und ich nehme auch stark an, dass das durch Verwendung dieser Funktionen gegeben ist. Allerdings fand ich dazu nichts Eindeutiges in der Doku. Ist obige Vorgehensweise korrekt? Bernd -- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist haben - und Geld." [Friedrich Nietzsche]

2 2