Python 2.6 DeprecationWarning


Soeben habe ich den Server auf Ubuntu 9.04 aktualisiert. Das lief astrein und alles funktioniert einwandfrei. Nur selbst installierte Python-Module musste ich "neu einbinden" (sprich: Symlinks neu setzen und fertig).

Aber da nun Python 2.6 die Standard-Python-Version ist und bei mir etliche Python-Skripte - selbst geschriebene und fremde - in Cron Jobs laufen, quillt mein Posteingang wegen Mails aus eben diesen Cron Jobs über. Und alle handeln von DeprecationWarnings, also Warnungen, das Modul xy mit Python 3.0 wegfallen wird. Nun ist dies natürlich ungemein praktisch - für den eigenen Code. Aber keine dieser Warnungen kommt von meinem eigenen Code, sondern von fremden. Grmpf.

Bisher seh ich noch keine Möglichkeit, das sauber zu lösen, bis die entsprechenden Programmierer das angepasst haben und die neuen Versionen über die gängigen Pakete verfügbar werden. Bis dahin bleiben zwei "unsaubere Lösungen":

- Wird das Skript direkt über python aufgerufen, reicht es, den Parameter -Wignore anzugeben. Das ignoriert aber alle Warnungen!

- Bei schweren Fällen geht nur ein gepflegter Eingriff in das Python-Modul selbst. Da etliche Python-Skripte Warnungen wegen dem sets-Modul ausgeben, kann diese durch ein Editieren der Datei /usr/lib/python2.6/sets.py und dem Auskommentieren des Codes unterdrückt werden:

#import warnings
#warnings.warn("the sets module is deprecated", DeprecationWarning,
#                stacklevel=2)

Ist aber zugegeben keine gute Lösung. Aber bis das "Problem" in allen Skripten gelöst sein wird, wird es noch dauern. Bisher scheint das auch nur beim sets-Modul notwendig zu sein.

Kennt jemand eine bessere Lösung? Bin für jede Hilfe dankbar.

PISA: PDF-Dokumente in Python einfach erstellt


Auf meiner Arbeit wurde sehr lange ein Word-Makro verwendet, um Text in eine bestimmte Form zu pressen und dann auszudrucken. Dieses Makro war nicht gerade einfach in der Bedienung und relativ fehleranfällig, überdauerte aber die Zeit von Office 97, Office XP bis hin zu Office 2003 - in Office 2007 funktioniert es schlicht nicht mehr.

Nun stand ich vor dem Problem, das Makro in Office 2007 wieder zu flicken (oh Graus), oder vielleicht gleich das Ganze in einer anderen Umgebung umzusetzen. Die Wahl war klar und die betroffenen Kollegen, die damit am Ende arbeiten würden, hatten nichts gegen meinen Vorschlag, eine kleine Webanwendung zu schreiben, die die Konvertierung macht und daraus ein PDF generiert.

Die Django-Applikation war schnell geschrieben, aber da ich noch nie in Python ein PDF erstellt hatte, dachte ich, dass wird ein ziemlich großer Aufwand - bis ich auf Pisa stieß. Das ist nicht der berühmt-berüchtigte Test für das Bildungssystem, sondern ist ein HTML/CSS-zu-PDF-Konverter für Python. Lizenziert unter der GPLv2 steht dem Einsatz nichts im Wege.

Wer also HTML/CSS kann, der kann damit auch ziemlich einfach PDF-Dateien erstellen. Ein Bild könnt Ihr Euch auf der Demo-Seite von Pisa machen. Die Handhabung ist simpel und in der Dokumentation steht alles, was man wissen muss.

Damit war das angesprochene Projekt in wenigen Stunden umgesetzt. Und kein Microsoft Office ist mehr nötig - nur ein Browser und ein PDF-Reader. Zu guter Letzt ist auch der Arbeitsplatz nicht mehr relevant. Die Kollegin kann den Druck anstoßen, wo auch immer sie gerade arbeitet.

Open Source macht einfach produktiver! Smile

Subversion beibringen, *.pyc-Files zu ignorieren


Wer Python-Projekte mit Subversion verwaltet, wird das leidige Thema kennen, das Subversion auch kompilierte Python-Dateien mit der Endung pyc beachtet. Mit folgendem Befehl kann das unterbunden werden: Die Endung *.pyc wird in jedem Verzeichnis zur Eigenschaft svn:ignore hinzugefügt und somit beachtet Subversion das nicht mehr.

svn -R propset svn:ignore "*.pyc" .

Irgendwo stand, dass Subversion in der neuesten Version pyc-Files nicht mehr beachtet würde. Damit wäre das hinfällig. Aber in SVN 1.5.1 ist das anscheinend noch nicht der Fall.

pyxml in Ubuntu anyone?


Heute wollte ich die DocBook-Ausgabe in MoinMoin aktivieren, aber ich erhielt nur einen Fehler:

ImportError: No module named ext.reader

Da fehlte also augenscheinlich was auf dem Server. Angeblich soll es reichen, python-xml (und python-lxml) zu installieren, aber das war schon installiert. Nach etwas Recherche fand ich heraus, dass in Ubuntu Hardy (und Intrepid auch) zwar die XML-Dinge installiert sind, allerdings als oldxml in site-packages verlinkt sind. Reichlich mysteriös. So klappt natürlich kein Import in irgendwelchen Python-Skripten.

Eine kurzfristige "Lösung", oder besser ein Workaround, ist das folgende:

cd /usr/lib/python2.5/site-packages
sudo ln -s oldxml/_xmlplus/ xml

Dann steht unter xml alles bereit, so dass Imports wieder funzen. Testen am besten im Python-Interpreter:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.dom.ext.reader import Sax
>>> exit()

Das funktioniert zwar, aber so richtig zufrieden bin ich damit nicht. Bei jedem OS-Update (Jaunty bald z.B.) könnte es evtl. da Probleme geben, also im Hinterkopf behalten und vor dem Update den Link lösen und schauen, ob es sich gebessert hat - falls nicht, kann der Link ja wieder gesetzt werden.

Python Cheat Sheet


Eine sehr schöne Sache ist dieses Cheat Sheet für Python-Entwickler. Das Wichtigste (bzw. oft verwendeste) schnell im Blick.

Empfehlenswerte Eclipse-Plugins


Wenn man Django-Projekte mit Eclipse bearbeitet, lohnt es sich, folgende Plugins zu installieren (neben PyDev logischerweise):

- GEF (wird vom HTML-Editor benötigt) wie in der GEF-FAQ beschrieben

- Amateras, ein HTML-Editor, damit man die Templates auch schön bearbeiten kann

- Wer mit SVN arbeitet, sollte noch Subclipse installieren.

Kennt noch jemand ein paar hilfreiche Plugins?

Weiter empfehlenswert ist, ein eigenes Projekt in Eclipse zu erstellen, dass den Django-Source enthält. Dieses kann man dann in seinen eigenen Projekten als Abhängigkeit definieren. Klickt man nun auf einen Bezeichner, sprint Eclipse sofort zur Deklaration direkt im Django-Code!

Django-Projekte in Eclipse debuggen


Um mit Eclipse ein Django-Projekt zu debuggen, sind folgende Schritte notwendig (dies bezieht sich auf die Eclipse-Version 3.2.2 aus den Ubuntu-Quellen, andere Versionen sind nicht getestet):

- Eclipse und PyDev installieren, falls noch nicht geschehen. Unter Ubuntu dazu die beiden Pakete "eclipse" und "eclipse-pydev" installieren, die die entsprechenden Abhängigkeiten auflösen.

- Eclipse starten und unter Window->Preferences->PyDev->Interpreter Python als Interpreter python suchen und auswählen - das ist in der Regel /usr/bin/python.
Unter PYTHONPATH den direkten Pfad zur Django-Installation eintragen (bei mir z.B. /opt/django/trunk/django).

Um Django-Projekte zu integrieren, muss man folgendes tun. Dabei sollte das Django-Projekt ganz normal über die manage.py erstellt worden sein, wie man es sonst auch macht. Ist das geschehen, setzt man da ein Eclipse-Projekt drauf:
- Ein neues Projekt in Eclipse erstellen über File->New project. Dort ein pydev-Projekt auswählen. Unter "project contents" das Häkchen entfernen und direkt den Pfad zum schon erstellten Django-Projekt wählen. Die manage.py z.B. sollte direkt in diesem Verzeichnis liegen.
"Create default 'src' folder and add it to the pythonpath?" kann dabei angehakt bleiben.

- Um das Debuggen zu ermöglichen, muss eine neue Debug-Konfiguration erstellt werden. Über Run->Debug... kann durch einen Doppelklick auf "Python Run" eine neue Konfiguration erstellt werden. Dort wird als Projekt das eben erstelle Projekt gewählt und als "Main Module" die Datei "manage.py" ausgewählt. Im Reiter "Arguments" trägt man unter "program arguments" noch "runserver --noreload" ein und klickt auf "Debug". Dann sollten Breakpoints funktionieren.

Django's Admin-App verwendet newforms - und zwingt zu Code-Anpassungen


Im Zuge des Sprints auf Django 1.0 wurde nun im trunk die Admin-App so aktualisiert, dass newforms verwendet werden. Zwar ergeben sich dadurch wirklich tolle Möglichkeiten, allerdings sind diese Änderungen leider nicht rückwärtskompatibel und man muss Dinge im eigenen Code zwangsläufig anpassen.
Aber aufgrund der tollen Dokumentation von Django ist das kein sonderlich großes Unterfangen, wie ich freudig festgestellt habe. Smile

Wer sich den neuesten trunk aus dem SVN auscheckt und dann den Entwicklungsserver startet, wird Fehlermeldungen wie z.B. diese erhalten:

TypeError: __init__() got an unexpected keyword argument 'prepopulate_from'

Das liegt daran, dass nun Model-Definitionen von Angaben für die Admin-App bereinigt wurde. Diese Angaben wandern nun in eine extra Klasse, die dann in der Admin-App registriert wird. Dies bringt einige Vorteile: Man kann munter neue Klassen von früheren ableiten und sich sogar mehrere Admin-Oberflächen basteln, die unter verschiedenen URLs erreichbar sind (zum Beispiel darf dann Klaus nur den Admin-Bereich Bäckerei betreten und neues Gebäck zur Datenbank hinzufügen, während Egon nur die Getränkdatenbank bearbeitet und neue Bier-Sorten eintragen kann). Außerdem macht das Model-Definitionen übersichtlicher und sorgt für eine logische Trennung.
Eine schöne Übersicht, was man damit alles anstellen kann, gibts im Django-Wiki.

Es gibt zu der Sache auch einen sehr guten Screencast, den man sich erstmal anschauen sollte in folgendem Artikel:

http://oebfare.com/blog/2008/jul/20/newforms-admin-migration-and-screencast/

Die Änderungen im Detail und was zu tun ist, kann man auch nochmal auf einer Wiki-Seite nachlesen.

Neugestaltung der Webseite oder mein Weg zu Django ...


Endlich ist sie fertig, zumindest in der ersten Beta-Version: meine neue Webseite, komplett in Django geschrieben, konform zu XHTML 1.0 Strict und mit validem CSS.

Ich hoffe, den werten Leser und Besucher spricht die neue Seite an. Am Design habe ich mich ein wenig an der Einfachheit von Google orientiert. Trotzdem sollte es ein relativ zeitloses Design sein, womit man auch noch in einigen Monaten oder Jahren zufrieden sein kann, und dessen Farben ein gutes Gefühl bei gleichzeitig guter Lesbarkeit gewährleisten. Und dabei sollten natürlich die Standards eingehalten werden, so dass die Seite überall gut lesbar ist, egal welcher Browser oder OS (iPhone konnt ich leider nicht probieren Wink ) und auch ohne CSS sollte sie gut strukturiert bleiben. Ich denke, dass ist mir soweit gelungen (jedenfalls in meinen Tests Two thumbs ). Yippie!

Aber warum denn überhaupt eine neue Webseite? War das alte Wordpress-Blog nicht gut? Huh