Das ist der Titel der Studienarbeit von Reto Schüttel und mir, die wir am Freitag pünktlich um 17:00 eingereicht haben. Die Arbeit hat viel Zeit und Nerven gekostet, aber auch Freude gemacht und ich denke das Ergebnis kann sich sehen lassen :).

Übersetzt heisst der Titel soviel wie Automatisierte Python-Refactorings mit Typinferenz. Für PyDev, eine Eclipse-basierte IDE für Python, haben wir die wohl nützlichsten Refactorings implementiert, wie zum Beispiel Rename Method, Rename Class und Rename Attribute. Screenshots und unseren Bericht gibts auf dem Wiki. Interessierte Python-Programmierer können das ganze relativ einfach über unsere Update-Site für Eclipse ausprobieren.

Nachfolgend noch das Abstract unserer Arbeit. Ach ja, und frohe Weihnachten :)!

Software development is often an unpredictable process, the goals change, an approach turns out to be inefficient or a complex part has to be split up into several pieces. Keeping up with this process often results in the need to make structural changes, so called refactorings. Automating these kinds of adjustments is often desirable, as it saves time and reduces the risk of faults.

There are several development environments available for the Python programming language, but only a few offer automatic refactoring. The aim of this project was to extend the refactoring support of PyDev, an Eclipse-based development environment. We implemented the following refactorings:

• Generate Docstring
• Inline Local Variable
• Extract Local Variable
• Rename Local Variable
• Rename Method
• Rename Attribute
• Rename Class

To be able to automatically rename methods, classes or attributes, it is essential to know the types of all involved objects. In a dynamically typed language like Python, the exact type of objects is not known before running the actual program. To still be able to determine these types in advance, a heuristic called type inference was implemented. Although the type inference heuristic still has some limitations, it turned out to be very powerful and an essential helper.

As more advanced refactorings often depend on knowing the type of objects, the type inference engine will make implementing these refactorings much simpler. But the engine also appears to be useful for many other common IDE tasks, like finding the references of a given attribute or method, searching for a definition or providing overall structural information.

Wie funktionieren eigentlich verteilte Versionsverwaltungssysteme? Ist der Satz von Pythagoras nur für Dreiecke? Was ist schon wieder der Unterschied zwischen Permutationen und Kombinationen?

Diese und andere interessante Fragen werden auf der Seite betterexplained.com auf verschiedene Arten (unterschiedliche Menschen brauchen unterschiedliche Erklärungen) angegangen und mit anschaulichen Bildern verständlich erklärt. Es ist das Blog von Kalid Azad, der gerne seine Erkenntnisse mit anderen teilt und der Spass daran hat, (komplizierte) Sachverhalte verständlich zu erklären.

Die Themen sind Mathematik, Programmieren und Kommunikation. Ich habe noch nicht alles angeschaut, aber beim Lesen der Artikel ist mir schon ein paar Mal ein Licht aufgegangen – ein gutes Gefühl :).

Die erste Alpha-Version von Python 3.0, auch bekannt als Python 3000 (scherzhaft nach dem voraussichtlichen Erscheinungsjahr benannt), ist auf der Python-Website verfügbar. Sie ist vor allem für Programmierer gedacht, die einen ersten Eindruck von Python 3 haben möchten.

Im Lauf des Jahres wird es noch mehrere Alpha-Versionen geben, im 2008 dann Betas und die finale Version ist für August 2008, also in einem Jahr geplant. Bin gespannt was zuerst draussen ist, Python 3 oder Ruby 2 – am Ende noch Perl 6 ;).

Bei Python habe ich ein gutes Gefühl, der ganze Prozess wird in diversen PEPs (Python Enhancement Proposals) ziemlich transparent dokumentiert und auch die Mailing-Liste Python 3000 ist informativ.

Diese Präsentation von Guido zeigt die wichtigsten Änderungen im Vergleich mit Python 2. Hier meine Zusammenfassung, mit Links zu den PEPs:

• Viele Altlasten (z. B. klassische Klassen) entfernt und generell Codebasis verbessert
• bytes und str anstatt str und unicode, also Strings sind standardmässig Unicode-Strings, zu/von bytes muss explizit konvertiert werden
• Ein-/Ausgabe überarbeitet, verschachtelbare Streams wie in Java, aber grundlegende Dinge bleiben einfach
• Neue String-Formatierung, "{0.name} ({0.alter})".format(person) anstatt "%s (%i)" % (person.name, person.alter)
• Abstrakte Basisklassen (ABCs) für eingebaute und eigene Klassen; ähnlich wie Interfaces von Java, nur dass Methoden auch Implementierung haben können und dank Mehrfachvererbung von mehreren abgeleitet werden kann
• Optionale Annotationen für Funktionsparameter wie zum Beispiel def haul(item: Haulable, *vargs: PackAnimal), die für Python selber keine Bedeutung haben, aber zum Beispiel für generische Funktionen verwendet werden können
• range(), zip(), map(), filter() geben Iteratoren zurück
• dict.keys() und ähnliche geben nicht mehr eine Liste zurück, sondern eine View (Sicht), was schneller ist

Ach ja, Python 3 wird keine geschweiften Klammern anstelle von Einrückung verwenden, hier Pythons Meinung dazu:

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

:). python -c 'import this' ist auch was lustiges zum ausprobieren.

Momentan sind für Bezeichner (z. B. Variablennamen) in Python nur ASCII-Zeichen erlaubt. Dies ist schade, da für nicht-englische Programmierer, die Bezeichner in ihrer Muttersprache schreiben wollen, nichts anderes übrig bleibt, als die Wörter ins lateinische Alphabet zu transkribieren – was zum Teil nur mit Einschränkungen möglich ist – oder zu versuchen, die Wörter ins Englische zu übersetzen.

Für Python 3.0 wurde PEP 3131 (Python Enhancement Proposal, Python-Verbesserungsvorschlag) geschrieben, der vorschlägt für Bezeichner die von Unicode dafür empfohlenen Zeichen-Bereiche zu erlauben.

Am Anfang war Guido van Rossum, der Autor von Python, dem Vorschlag gegenüber eher ablehnend gestimmt. Es gab sowohl Fürsprecher als auch Widersprecher, doch nach viel Diskussion konnte Guido umgestimmt werden und er nahm den PEP an.

Ich war von Anfang an dafür und bin froh, dass der PEP angenommen wurde. Dies ist ein weiterer kleiner Schritt weg von der ASCII-Armut und hin zur Unicode-Vielfalt, jee :).

In der Prüfungszeit gibt’s viel zu tun, aber ab und zu muss man was anderes machen als lernen :). Man kann zum Beispiel versuchen, was ähnliches wie die CD-Cover-Ansicht von iTunes zu implementieren.

Auf die Idee gekommen bin ich durch einen Blogeintrag von Zack Rusin, einem Qt-Entwickler. Der hat es natürlich in Qt nachgebaut, und zwar in ungefähr 300 Zeilen Code, ganz geil.

Für meine eigene Implementierung hätte ich QtRuby nehmen können, aber den Qt-Teil hat ja Zack Rusin schon gemacht. Darum entschied ich mich für Cairo und Python. Cairo ist eine C-Bibliothek zum Zeichnen von 2D-Grafiken und es gibt eine offizielle Python-Anbindung namens Pycairo. Für das Fenster hab ich GTK+ verwendet, natürlich auch mit Python.

Hier ein Bild, wie’s rausgekommen ist:

Sieht doch schon ganz nett aus, oder?

Mit Cairo kann man leider nur affine Transformationen ausführen. Deshalb sind perspektivische Verzerrungen nicht möglich, was für weitere Covers schräg neben dem in der Mitte nötig wäre.

Der Code ist 70 Zeilen lang. Der schwierigste Teil war, die richtige Transformations-Matrix rauszufinden, um das Spiegelbild zu bekommen:

mirror_m = cairo.Matrix(1, 0, 0, -self.mirror_factor,
                        0, img_h + self.mirror_factor*img_h)

Das self.mirror_factor ist 0.7 und entspricht der Stauchung. Der Wert wird negativ übergeben, um die Spiegelung zu erhalten. Das letzte Argument ist dafür da, die Spiegelung an die richtige Position zu bringen. Danach wird noch ein Verlauf von halb durchsichtig bis durchsichtig darübergelegt, und fertig ist das Spiegelbild.

Den Code zum ausprobieren gibt’s hier. Das anzuzeigende Bild muss cover.png heissen und im selben Verzeichnis liegen.

Beides sind relativ neue, viel gelobte Web-Frameworks in dynamischen Programmiersprachen – Rails in Ruby und Django in Python. Der englischsprachige Artikel A Rails/Django Comparison vergleicht die beiden und befindet sie für ziemlich gleichwertig.

Habe Rails mal angeschaut, allerdings noch nie was richtiges damit gemacht. Django finde ich interessant, da es Rails ähnlich ist, aber eigene Wege geht. Zum Beispiel werden in Django die Modelle nicht aus einer bestehenden Datenbank abgeleitet, sondern man gibt sie in Python-Code an, woraus dann die Datenbank generiert wird. Meiner Meinung nach ist der Ansatz von Django sauberer und flexibler.

Dann wäre da Djangos magic-removal branch, ein Entwicklungszweig, bei dem es darum ging, unnötige “Magie” loszuwerden und Ordnung zu schaffen – etwas das Rails vermutlich auch nicht schaden würde.

Auch das Dokumentieren scheint anders zu laufen, es wird an einem freien Django-Buch mit 21 Kapiteln geschrieben, wo man beim Lesen gleich Verbesserungsvorschläge anbringen kann.

Ich bin auf die weitere Entwicklung der beiden Projekte gespannt. Django ist bei mir auf jeden Fall mal als Kandidat für ein allfälliges zukünftiges Webprojekt vorgemerkt.