Mailman 3 April 2013 - python-de

Re: [Python-de] Möglicher Fehler im Postgres-Treiber 'pg8000'
by Volker Böhm 13 Apr '13

13 Apr '13

Am Sat, 13 Apr 2013 19:33:54 +0200 schrieb Diez B. Roggisch: > On Apr 13, 2013, at 7:00 PM, Volker Böhm wrote: > >> Am Sat, 13 Apr 2013 18:09:17 +0200 schrieb Diez B. Roggisch: >> >>> Ich finde es komisch, dass du zwei Cursor aufmachst, von denen einer >>> ueber Transaktionen hinweg aufgehalten wird. Das ist IMHO unsauber und >>> undefiniert. >> >> Finde ich gar nicht. Ich arbeite seit mehr als zehn Jahren mit Postgres >> (meist mit Java aber auch mit Python, früher mit Perl) und habe noch >> nie von einem Programm aus mehr als eine Connection im selben Thread >> aufgemacht. In einem Dutzend Methoden mit drei bis acht Queries und >> Update-Statements zu arbeiten, halte ich für einen ganz normalen >> Vorgang; und _selbstverständlich_ auf einer einzigen Connection, weil >> man - zumindest wenn man mit Transaktionen arbeitet - sich sonst viel >> zu schnell einen Deadlock produziert. > > Das ist nicht das, was ich gesagt habe. Das komische sind nicht die > verschiedenen Cursor, sondern deren Nutzung ueber Transaktionsgrenzen > hinweg. Das habe ich noch nie so gemacht (oder machen muessen). Und es > ist auch semantisch finde ich hoechst fraglich: was bekommt denn ein > Cursor zu sehen, der mit einem bestimmten Transaktions-Isolations-Level > läuft, wenn du zwischendurch ein COMMIT machst, das Daten anderer Cursor > zurueckgeschrieben hat. Sind die dann sichtbar, unsichtbar, undefiniert? > > Und weil das so kompliziert ist, kann Postgres das auch nicht. So > einfach ist das :) > > http://www.postgresql.org/docs/9.1/static/plpgsql-cursors.html > > 39.7.3. Using Cursors > > All portals are implicitly closed at transaction end. Therefore a > refcursor value is usable to reference an open cursor only until the end > of the transaction. > > >> Ja, wenn mir nicht noch jemand nachweist, dass ich groben Bockmist >> verzapft habe :-) werde ich das wohl auf tun. Denn pg8000 ist wohl >> derzeit der einzige native Python-Treiber für Postgres 2.x.. Und mit >> den anderen Treibern, die eine DLL benutzen, kämpfe ich gerade unter >> cygwin :- > > Denke ich habe ich nachgewiesen ;) Wenn psycopg2 et al das > unterstuetzen, dann ist das also eher feature statt bug. Das kannst du > natuerlich beantragen. Ich frage mich natuerlich jetzt, *WIE* psycopg2 > das denn genau macht. Denn offensichtlich sind interne Strukturen der > Postgres DB dazu nicht vorbereitet, und so muesste zb ein implizites > tracking des lese-fortschrittes erfolgen. Kann ich mir schwer > vorstellen. Leider nicht so ganz :-) Dein Zitat (Kapitel 39.7.3) stammt aus der Beschreibung von PL/SQL und nicht aus der Beschreibung zum SQL-Cursor. Die ist in der Kommando- Referenz unter 'DECLARE' zu finden. > Ein kurzer Blick in den Sourccode von psycopg2 ist da auch nicht > erhellend, die benutzen auch einfach deklarierte Cursor. > > UU liegt es an anderen Default-Transaktions-Verhaltensweisen - zB > Autocommit oder sowas - zwischen den Adapter-Implementierungen. Ahh, jetzt ahne ich worauf Du hinaus willst. Ich arbeite meistens mit Java. Da hat man eine Connection, aus der man mit einer SQL-Anweisung ein (Prepared-)Statement erstellt und dann beim Execute einen ResultSet erhält. Ich hatte mir bei Python das auch immer so vorgestellt nur dass der Python-Cursor erst ein Statement und nach der Ausführung den ResultSet hält. Auf die Idee, dass Python einen echten PostGres-Cursor benutzt, bin ich nie gekommen. Ich habe so was noch nie benutzt, aber zumindest in der aktuellen Beschreibung steht: WITH HOLD WITHOUT HOLD WITH HOLD specifies that the cursor can continue to be used after the transaction that created it successfully commits. WITHOUT HOLD specifies that the cursor cannot be used outside of the transaction that created it. If neither WITHOUT HOLD nor WITH HOLD is specified, WITHOUT HOLD is the default. Dieser Modifier wird übrigens erstmalig in PostGres 7.4 erwähnt. Also taucht die Frage auf, ob es unter Python das Äquivalent zu einem ResultSet gibt, das per se keine Einschränkung durch COMMITs kennt. Wenn die anderen (PsycoPg2 und PyGreSQL) aber mit der WITH-HOLD-Variante arbeiten, wäre das nicht nötig. Es bleibt spannend ... mfg Volker -- Volker Böhm Tel.: +49 4141 981152 www.vboehm.de Voßkuhl 5 Fax: +49 4141 981154 D-21682 Stade mailto:volker@vboehm.de

2 1

abstrakter Datenbank Layer
by Philipp Kraus 13 Apr '13

13 Apr '13

Hallo, ich suche für Python eine abstrakte Datenbankanbindung, über die ich Datebanken / Tabellen / Indizies etc erstellen kann und zusätzlich eben Datenbankinhalt verändern kann. Das ganze soll wenn es die Datenbank unterstützt auch transaktionssicher sein. Schön wäre ein Support für NoSQL Datenbanken. Ich hatte bisher http://www.sqlobject.org/ gefunden, das scheint schon mal in die entsprechende Richtung zu gehen. Ich möchte datenbankunabhängig eben die Tabellen erzeugen und verändern können, sowie eben Datensätze bearbeiten können. Was gibt es da alles für Möglichkeiten mit Python. Danke für die Hilfe und schönes Wochenende Phil

3 4

Re: [Python-de] Möglicher Fehler im Postgres-Treiber 'pg8000'
by Volker Böhm 13 Apr '13

13 Apr '13

Am Sat, 13 Apr 2013 18:09:17 +0200 schrieb Diez B. Roggisch: > Ich finde es komisch, dass du zwei Cursor aufmachst, von denen einer > ueber Transaktionen hinweg aufgehalten wird. Das ist IMHO unsauber und > undefiniert. Finde ich gar nicht. Ich arbeite seit mehr als zehn Jahren mit Postgres (meist mit Java aber auch mit Python, früher mit Perl) und habe noch nie von einem Programm aus mehr als eine Connection im selben Thread aufgemacht. In einem Dutzend Methoden mit drei bis acht Queries und Update-Statements zu arbeiten, halte ich für einen ganz normalen Vorgang; und _selbstverständlich_ auf einer einzigen Connection, weil man - zumindest wenn man mit Transaktionen arbeitet - sich sonst viel zu schnell einen Deadlock produziert. > Natuerlich ist das schon komisch, dass psycopg2 das unterstuetzt, pg8000 > aber nicht. > > Um dein Problem zu loesen, wuerde ich einfach zwei Verbindungen > aufmachen, und aus der einen Arbeitspakete fuer die andere generieren. Das ist natürlich in diesem einfachen Fall ein möglicher Workaround. > Oder deine Queries so umschreiben, dass das SELECT nur Datensaetze > liefert, die im Durchlauf davor noch nicht vearbeitet wurden. Eigentlich wollte ich natürlich nur einen Durchlauf machen aber als Notanker ist das echte Programm so geschrieben das es nach einem Abbruch an der richtigen Stelle wieder aufsetzen kann. Aber derzeit habe ich mit pg8000 alle 100 Sätze einen Abbruch; und das macht keinen Spaß. > Last but not least - wenn du das wirklich als Fehler in pg8000 ansiehst, > solltest du das dessen Autor melden. Das gut gemachte Beispiel hilft da > sicher. Denn hier wird sich kaum jemand so intim mit dem PG-Protokoll > auskennen. Ja, wenn mir nicht noch jemand nachweist, dass ich groben Bockmist verzapft habe :-) werde ich das wohl auf tun. Denn pg8000 ist wohl derzeit der einzige native Python-Treiber für Postgres 2.x.. Und mit den anderen Treibern, die eine DLL benutzen, kämpfe ich gerade unter cygwin :- ( mfg Volker -- Volker Böhm Tel.: +49 4141 981152 www.vboehm.de Voßkuhl 5 Fax: +49 4141 981154 D-21682 Stade mailto:volker@vboehm.de

2 1

Möglicher Fehler im Postgres-Treiber 'pg8000'
by Volker Böhm 13 Apr '13

13 Apr '13

Hallo, beim Versuch mit dem Modul 'pg8000' auf eine Postgres-Datenbank zuzugreifen bin ich auf einen Fehler gestoßen, der meiner Meinung nach im pg8000 enthalten ist. Das Programm macht eine Query und arbeitet der Reihe nach alle Sätze ab. Dabei erstellt es neue Sätze für eine andere Tabelle, die dort mit INSERT hineingeschrieben werden. Wenn ich alle Sätze verarbeite und zum Schluss erst ein COMMIT mache, geht alles gut. Da das Originalprogramm aber ca. 450.000 Sätze verarbeitet und dabei mehr als 2.000.000 neue Sätze in die Ziel-Tabelle schreibt, wofür es ca. 100 Stunden braucht, wollte ich natürlich zwischendurch gelegentlich ein COMMIT machen. Wenn ich dies tue bricht das Programm aber kurze Zeit später - genauer nach 100 Sätzen - mit dem Fehler pg8000.errors.ProgrammingError: ('ERROR', '34000', 'portal "pg8000_portal_10007" does not exist') ab. Ich habe das Programm soweit vereinfacht, dass sich der Fehler reproduzieren lässt: --------- schnipp --------------------------------------------- #!/usr/bin/env python import random from pg8000 import DBAPI as DB #import psycopg2 as DB #import pgdb as DB random.seed() conn = DB.connect(host = 'myhost', database = 'mydb', port = 5432, user = 'me', password = 'mypwd') cur1 = conn.cursor() cur2 = conn.cursor() #------------------- Tabellen erstellen ----------------------- cur1.execute('DROP TABLE IF EXISTS t1') cur1.execute(''' create table t1 ( a integer, b integer)''') cur1.execute('DROP TABLE IF EXISTS t2') cur1.execute(''' create table t2 ( c integer, d integer)''') #------------------- t1 befüllen ------------------------------ for i in range(10000): cur1.execute(''' INSERT INTO t1(a,b) VALUES(%s, %s)''', (random.randint(1, 1000000), random.randint(1, 1000000))) conn.commit() #------------------- Hier geht's los -------------------------- cur1.execute(''' SELECT a,b FROM t1'''); row = cur1.fetchone() while row: print row a, b = row cur2.execute(''' INSERT INTO t2(c, d) VALUES(%s, %s)''',(3*a, 5*b)) conn.commit() row = cur1.fetchone() conn.close() --------- schnapp --------------------------------------------- Habe ich etwas übersehen oder mache ich etwas Prinzipielles falsch? Wenn ich 'psycopg2' oder 'PygeSQL' als Treiber benutze (Tausch der IMPORT- Zeilen), tritt der Fehler nicht auf. Es sieht so aus, als würde der COMMIT-Befehl den Cursor cur1 Schließen und dann nur noch die restlichen gepufferten Sätze gelesen werden. Es kommt übrigens nicht auf die Anzahl der geschriebenen Sätze oder die Anzahl der COMMITs an: Ein einziges COMMIT sorgt dafür, dass nach 100 Sätzen Schluss ist. mfg Volker -- Volker Böhm Tel.: +49 4141 981152 www.vboehm.de Voßkuhl 5 Fax: +49 4141 981154 D-21682 Stade mailto:volker@vboehm.de

2 2

Re: [Python-de] Windows: Postgres-Zugriff ohne Server-Installation
by Volker Böhm 13 Apr '13

13 Apr '13

Am Wed, 10 Apr 2013 22:35:25 +0200 schrieb Diez B. Roggisch: > Wenn man kein vorkompiliertes Binary von psycopg2 installieren will oder > kann, dann muss man wohl oder uebel kompilieren - und zwar gegen die > Postgres DB API, Headerfiles sowie DLLs. Dazu braucht man auch unter > Linux mindestens die dev-Pakete, ob die fuer den client separat > vorliegen mag ich gerade nicht gucken. > > pg_config ist ein Programm, btw. > > Wieso du aber Stunden brauchst, und dann das hier nicht findest > > http://www.stickpeople.com/projects/python/win-psycopg/ Erstens habe ich mich nie gegen ein vorkompiliertes Binary gewehrt; im Gegenteil: Ich suche verzweifelt danach. Und außerdem steht auf der genannten Seite - wo ich vorher schon mehrfach war - zu lesen: 'Also, it has been noted that the psycopg2 installers do not work under a virtualenv environment.' (da fällt cygwin wohl auch drunter). Und probiert hatte ich die Installation damit auch aber es kam nur eine schwachsinnige Meldung, in der Registry sei kein Python eingetragen. > was durch googeln von "psycopg2 windows installer" zustande kommt - das > musst du schon selber wissen. Jede Menge Schwachsinn, der entweder überhaupt keine Grundvoraussetzungen erwähnt oder der aufzählt, man möge zuerst Postgres installieren. Und einen Postgres-_Server_ zu installieren, um einen Client-Zugriff zu ermöglichen, kann doch nicht ernst gemeint sein. Ein Postgres-Klient (sprich: sowohl PgAdmin3 als auch psql) ist natürlich schon lange auf dem Rechner installiert. > Und alternativ auch noch > > https://github.com/mfenniak/pg8000 > > fuer eine pur-python-Implementierung des Netzwerkprotokolls von > postgres. Besten Dank! Das war die Lösung aller Probleme. Hier gibt es einen Verweis auf die Homepage des Projektes, die wiederum einige direkt benutzbare Downloads anbietet und mich vor allem auf die Idee brachte einfach mal ein easy_install pg8000 zu versuchen, was auf Anhieb funktionierte. Und auch die weitere Benutzung dieses Treiber funktioniert ohne Probleme. Datenbanktreiber (für jede Programmiersprache), die auf externen Fremd- Bibliotheken (.dll bzw. .so) aufbauen, waren schon immer eine Scheiß-Idee und sind nur in wenigen Fällen (z.B. für SQLite => es gibt keinen Datenbank-Server, der Treiber _ist_ die Datenbank oder für DB2 => die Serververbindung ist nicht immer ein einfacher TCP/IP-Socket sondern kann auch auf einem heute fast unbekannten Großrechner-Netzwerk-Protokoll aufgesetzt sein) sinnvoll. Und warum gerade zwei der verbreitetsten Postgres-Treiber für Python unter Windows eine Postgres-_Server_-Installation voraussetzen, wird mir wohl immer ein Rätsel bleiben. Besten Dank für die schnelle Hilfe. mfg Volker -- Volker Böhm Tel.: +49 4141 981152 www.vboehm.de Voßkuhl 5 Fax: +49 4141 981154 D-21682 Stade mailto:volker@vboehm.de

3 2

Karlsruhe Python User Group, 19.04.2013, 19 Uhr
by Jürgen A. Erhard 12 Apr '13

12 Apr '13

Die Karlsruher Python User Group (KaPy) trifft sich wieder. Ja, es gibt uns noch! :D Am 19.04.2013, um 19 Uhr, in den Clubräumen des Entropia e.V. (http://entropia.de/wiki/Anfahrt). So wie eigentlich jeden 3. Freitag im Monat. Es gibt auch eine Mailingliste auf https://lists.bl0rg.net/cgi-bin/mailman/listinfo/kapy.

1 0

Python Firmen in Berlin
by Marcelo Milo 11 Apr '13

11 Apr '13

Hello pythonistas, my name is Marcelo Milo and I'm planning to study in Germany next months, I have interested to learn German and live in Germany for an indefinite time. I have visited the country a few times and really enjoyed it, so I started to see some job opportunities in berlin, so someone have idea about good companys or startups that work with python in Berlin ? I work with python/django several years with experience in Ireland and Brazil. Thank you guys! Danke!

4 4

Windows: Postgres-Zugriff ohne Server-Installation
by Volker Böhm 10 Apr '13

10 Apr '13

Hallo, nach einigen Stunden Recherche stehe ich jetzt kurz vor der Detonation: Ist es in Python unter Windows möglich, einen Zugriff auf eine Postgres- DB zu installieren, ohne einen kompletten Postgres-Server zu installieren? Und wenn ja wie? Bisher habe ich psycopg2 und PyGreSQL (jeweils mit easy_install) ausprobiert. Und bei beiden die gleiche Fehlermeldung: 'pg_config tool not available' bzw. 'pg_config executable not found'. Und alle (gefühlte 8743 Stellen im Web) reden immer davon, man solle Postgres installieren. Ich habe genug installierte Postgres-Server; aber was hat sowas auf einem Windows-Notebook zu suchen? Ich sehe ja ein, dass - im Gegensatz zu anderen Programmiersprachen (wie z.B. Java) - in Python scheint's eine _externe_ Bibliothek benötigt wird, um einen Zugriff auf einen Postgres-Server zu ermöglichen. Aber es kann doch nicht wahr sein, dass man für so eine popelige DLL - oder was auch immer dieses ominöse pg_config.??? auch ist - einem armen Windows-Rechner mit einem ganzen Postgres-Server zumüllen muss. Ach ja: Das Frust-Objekt ist ein Notebook mit Windows 7 und cygwin. Ich hoffe, ihr könnt mir irgendwie weiterhelfen, bevor das Ding in der Elbe landet. mfg Volker PS: Unter einem beliebigen Linux installiert man übrigens einfach das Paket 'python-psycopg2' und der Drops ist gelutscht. Warum muss alles unter Windows eigentlich immer so kompliziert sein? -- Volker Böhm Tel.: +49 4141 981152 www.vboehm.de Voßkuhl 5 Fax: +49 4141 981154 D-21682 Stade mailto:volker@vboehm.de

2 1

Re: [Python-de] Dreieck zeichnen so einfach wie möglich
by Hermann Riemann 10 Apr '13

10 Apr '13

Thomas Lenarz schrieb: > Ergebnis: Die erste Strecke A zeichnen. Dann mit einem Zirkel von den > beiden Endpunkten jeweils Kreise in der Länge der beiden anderen > Strecken B und C zeichnen. Die beiden Schnittpunkte der Kreise ergeben > dann jeweils einen korrekten Kandidaten für den dritten Punkt. > Das Verfahren auf dem Computer zu simulieren stelle ich mir aber > aufwendig vor... Strecke A habe die Endpunkte x0,y0 und x1,y1. Dur rufst die Funktion male Kreis_mit_farbe_ausgefuellt (x0,y0, laenge0, farbe0) und male Kreis_mit_farbe_ausgefuellt (x1,y1, laenge1, farbe1) auf und suchst kleine Rechtecke die farbe0, farbe1 und Hintergrundfarbe enthalten. Ist zwar rechnerisch aufwendiger, aber einfacher zu verstehen, als wenn man mit ein paar geometrischer arithmestische Berechnungen die 2 Punkte x2,y2 sucht. Was dazu notwendig ist, sind Systeme die sowohl Funktionen zum Kreise malen anbieten (SDL (pygame) scheidet hier aus.) als auch Pixel lesen können. ( *.svg scheidet hier aus.) Ob es gtk bzw qt können, weiß ich nicht. Hermann der sich hier manchmal nach dem Atari ST zurücksehnt, wo sowas einfach ging. -- http://www.Hermann-Riemann.de

1 0

Re: [Python-de] Dreieck zeichnen so einfach wie möglich
by Benedikt Schwarz 10 Apr '13

10 Apr '13

Am 08.04.2013 19:23, schrieb Thomas Lenarz: > Am 07.04.2013 16:51, schrieb Benedikt Schwarz: >> wie zeichnet man in Python am einfachsten ein Dreieck? >> >> Mit Tkinter oder Pygame habe ich zwar schon entsprechenden Beispielcode >> ergoogelt, aber so richtig selbsterklärend war das dann doch nicht. Am >> liebsten würde ich nur 2 Längen (a, b) und einen Winkel (alpha) angeben >> und die restliche Arbeit der Funktion überlassen. > > Das ist eine interessante Frage. Habe auch mal in die alte > Formelsammlung geguckt und dachte erst. Hmm! Ohne Trigonometrie nicht > hinzubekommen. Die Idee von Reimar mit der Turtlegrafik ist da natürlich > der richtige Weg: > > Wenn man z.B.: ein Dreieck zeichnen möchte, dass durch zwei Strecken > a=55 und b=77 in einem Winkel von 66 aufgespannt wird, könnte man es wie > folgt angehen: > >>>> import turtle >>>> turtle.forward(55) >>>> turtle.left(180-66) >>>> turtle.forward(77) >>>> turtle.goto( (0,0) ) > > Die Schildkröte fängt am Punkt (0,0) an zu laufen. Der Winkel ist dann > eben irgendwo in der Mitte der zurückgelegten Strecke. > Das absolute "goto" zum Ursprungspunkt ist, glaube ich, wenig > "turtelig". Ich weiß nicht, ob Logo das früher beherschte. Aber es ist > effektiv.... ;-) Man kommt damit bestimmt schneller und einfacher ans Ziel als alle Eckpunkte/Seitenlängen eines Dreiecks mithilfe von Winkelfunktionen zu bestimmen. Nur was macht man, wenn kein Winkel, sondern alle 3 Seitenlängen gegeben sind? > Man kann die Schilkröte natürlich vor der Zeichen-Aktion mit > eingezogenem Stift erst einmal an eine absolute Position stellen und auf > einen bestimmten Winkel drehen. So kann man dann die Lage des Dreiecks > auf der Fläche bestimmen. Was meinst du mit "eingezogenem Stift"? Gruß Benedikt Schwarz

4 3