Zugriff auf postgreSQL mit psycopg2 und cgi

[KlausMerkert]

Liebe Foren-Teilnehmer,

ich bin Lehrer und möchte mit meinen Schülern mit Hilfe von Python auf eine postgres-Datenbank zugreifen. Erste Versuche dazu kann man unter
http://www.hsg-kl.de/faecher/inf/datenb ... /index.php
sehen. Leider habe ich nicht genug Dokumentation zum Thema gefunden.
So bleibe ich schon beim Versuch ein falsches Einloggen mit try-except abzufangen mit einem 'Internal Server Error' hängen. Vielleicht kennt jemand eine gute Quelle im Netz, wo wir uns kundig machen können.

Im Voraus vielen Dank für die Mühe!

Klaus Merkert

[EyDu]

Ich habe mal Google nach "python psycopg2 connect" gefragt und das liefert mir:

Code: Alles auswählen

conn = connect("dbname='terra1' host='localhost' user='gxx' password='geheim'")

Mal so geraten.

[Y0Gi]

Wenn der Server mit einem "500 Internal Server Error" antwortet, sollte der Traceback in der error.log (o.ä.) des Webservers zu finden sein.

Um Entwicklung und Fehlersuche zu vereinfachen, kann man den Datenbank-Zugriffs-Part in ein separates Modul `database.py` o.ä. auslagern und separat dessen Funktion testen. Das klappt allerdings nur, wenn eine Shell auf dem Server benutzbar oder auf dem lokalen Entwicklungsrechner idealerweise die gleiche Software installiert ist sowie der Zugriff auf die selbe Datenbank alternativ über das Netzwerk funktioniert oder lokal ebenfalls eine solche Datenbank existiert. Dies kann andere Probleme mit sich bringen, so dass eine zentrale Datenbank mit den aktuellen Daten einfacher handzuhaben sein dürfte.

[KlausMerkert]

Vielen Dank, tatsächlich war error-ssl.log nützlich. Die Lösung in
http://www.hsg-kl.de/faecher/inf/datenb ... /index.php
erscheint mir aber wenig elegant.
Bleibt weiterhin die Frage nach Dokumentationen bzw. Beispielen.

Viele Grüße

Klaus Merkert

[BlackJack]

@KlausMerkert: Bitte keine `*`-Importe verwenden. Damit holt man sich alles mögliche in den Namensraum des importierenden Moduls. Wenn man das oft und überall macht, gibt es früher oder später Namenskollisionen und wenn importierte Module ihrerseits alles mögliche per `*`-Import importieren, führt man das Konzept von Modulen ad absurdum.

Bei SQL-Select-Anweisungen sollte man möglichst auch kein '*' verwenden. So sieht man im Programm nicht, zu was dieses Sternchen alles expandiert. Das Programm ist auch nicht besonders robust gegenüber Schemaänderungen, wenn man zum Beispiel Spalten zu Tabellen hinzufügt, die man aber in der Abfrage gar nicht braucht.

Je nach Datenbank und Schema muss man hier jetzt auch aufpassen, dass man `unicode`-Objekte, die von der Datenbank kommen, korrekt kodiert.

Last but not least: ``for i in range(len(obj)):`` ist schlechter Python-Stil, weil man in 99% der Fälle keinen Umweg über einen Index braucht und da wo man *zusätzlich* einen Index benötigt, auch die `enumerate()`-Funktion verwenden kann. "Pythonisch" sähe das also eher so aus:

Code: Alles auswählen

print '<table class="tab1">'
for nr, row in enumerate(rows):
    print '  <tr>'
    print '    <td>%d</td>' % (nr + 1)
    for item in row:
        print '    <td>%s</td>' % item
    print '  </tr>'
print '</table>'

[gerold]

Dokumentation

Hallo Klaus!

Keine Dokumentation, aber ein kleines Beispiel:
http://www.python-forum.de/topic-12304.html
Vielleicht kannst du damit etwas anfangen.

mfg
Gerold

[KlausMerkert]

Vielen Dank,

das sind nützliche Tipps!

Viele Grüße

Klaus Merkert

[Leonidas]

Sosehr ich es gut finde, dass du Python lehrst muss ich aber sagen dass der Code ziemlich grausam ist!

Ein paar Verbesserungsvorschläge:

• ``#!/usr/bin/python`` funktioniert nur, solange Python auch wirklich dort liegt. Das ist speziell bei selbstgebauten Pythons und BSDs nicht mehr so. ``#!/usr/bin/env python`` wird generell bevorzugt, was dieses Problem nicht hat.
• Keine *-Imports, siehe [wiki]Import[/wiki]
• SQL-Statements würde man üblicherweise groß schreiben.
• Statt HTTP-Equiv wäre es sinnvoller das Encoding direkt im Content-Type-Header mitzuschicken. Ist eh die sauberere Lösung.
• Man braucht keine HTML-Entities mehr wenn man das Encoding richtig angibt.
• Inline Kommentare und Kommentare die falsch eingerückt sind, sind wahnsinnig störend.
• Code direkt im Modul vermeiden, das würde man viel besser in Funktionen strukturieren.
• Der Code schreit nach einer Template-Sprache, das HTML mit String-Konkatenation ist weder lesbar noch simpel noch irgendwas anderes. Brauchbare Templatesprachen gibt es genug, Jinja oder Mako bieten sich an.
• Bei einem ``except:`` immer auch die konkrete Exception angeben, die man fangen will.
• Warum nutzt ihr einmal UTF-8 und beim anderen mal ISO-8859-1?
• Es wäre generell besser wenn ihr statt auf CGI auf WSGI setzen würdet. Ihr wollt das wohl möglichst low-level haben, deswegen empfehle ich auch kein Framework, aber WSGI sollte man schon nutzen, sonst lernen die Schüler etwas, dass kein halbwegs vernünftiger Python-Programmierer machen würde.

Wie gesagt, ich finde deinen Ansatz aber gut, und +1 für die Wahl der richtigen Datenbank und Programmiersprache

Ich habe generell ein wenig auf der Informatik-Seite des Gymnasiums herumgesurft und muss sagen dass die Inhalte schon cool klingen. Speziell beim Punkt "Compilerbau" aber auch "Logische Programmierung" und "funktionale Programmierung" wünsch ich mir ich hätte so einen Leistungskurs gehabt, damals. Was du dir auch anschauen kannst sind stackbasierte Sprachen wie Factor und PostScript (gerade Postscript ist in der Hinsicht interessant, weil man damit interaktiv Bilder zeichnen kann und Factor, weil es eine ziemlich gelungene Sprache ist).

[KlausMerkert]

Vielen Dank für die Verbesserungsvorschläge. Manches leuchtet mir sofort ein, manches muss ich mir noch genauer ansehen. Jedenfalls habe ich viele fruchtbare Anregungen bekommen.

Viele Grüße

Klaus Merkert

[Leonidas]

Manches leuchtet mir sofort ein, manches muss ich mir noch genauer ansehen.

Wenn du fragen hast, dann meld' dich, wir beantworten dir gerne alle Unklarheiten.