My Universe Logo

My Universe Blog » Entries Tagged as python

Bleifreie Schwalbe macht Bruchlandung

Posted by Jesco Freund at Nov. 7, 2011 12:22 p.m.

In Go: First Contact hatte ich mir einen schnelleren und vor allem zu echtem Multithreading fähigen Python-Interpreter gewünscht. Damals wurde ich auf Unladen Swallow aufmerksam gemacht, ein Projekt, das zu jener Zeit auch die Unterstützung Googles genoss. Doch offenbar hat man sich dort entschieden, sich eher auf Go zu konzentrieren – das Unladen Swallow Projekt wurde zur verwesenden Projektleiche.

Nicht unerheblich zum Scheitern dürften auch die hohen technischen Hürden beigetragen haben. So gelang es nicht, durch Einsatz eines JIT und eines Garbage Collectors sowie Verzicht auf den GIL ein besseres Laufzeitverhalten zu erreichen – im Gegenteil, viele Module liefen auf den Entwicklungsversionen des Unladen Swallow Codes langsamer. So verwundert es auch nicht, dass letztlich auch PEP 3146 auf der Halde toter PEPs beerdigt wurde.

Doch was bedeutet das Ende von Unladen Swallow? Für viele Python-Programme erst mal gar nichts. Der Standard-Interpreter (CPython) bietet für die meisten Einsatzzwecke ausreichende Geschwindigkeit. Die Python Standardbibliothek ist nach wie vor eine reiche und gute Sammlung nützlicher Programmbausteine. Auch parallele Programmierung ist mit Python nach wie vor möglich, nur ist man eben auf die Nutzung des multiprocessing-Moduls festgelegt, wenn tatsächlich parallele Ausführung von Programmteilen benötigt wird.

Für die Zukunft von Python bedeutet das aber, dass die Sprache einen Makel weiter mit sich herumschleppt: Es wird auf absehbare Zeit nicht möglich sein, Threads tatsächlich parallel auszuführen. Durch die steigende Verbreitung von SMP-Systemen ist das aber auf Dauer nicht akzeptabel, da es die Eignung von Python zu sehr einschränkt. In einigen Bereichen lässt sich das kompensieren (z. B. durch Ausweichen auf multiprocessing), in anderen aber nicht. So wünschenswert es aus meiner Sicht wäre, aber solange hier keine Lösung gefunden wird, ist Python für mich keine Allzweck-Waffe für den Programmier-Alltag.

No comments | Defined tags for this entry: Go, google, programming, python

Python IDE All Over Again

Posted by Jesco Freund at Oct. 4, 2011 6:36 p.m.

Ich weiß, zu dem Thema gibt es gefühlt mindestens tausend Blogposts – trotzdem möchte ich dazu ein paar Worte loswerden. Eine funktionierende und benutzbare Python-IDE zu bauen, scheint ungeheuer schwierig zu sein. Noch dazu eine, die unter FreeBSD ohne Einschränkungen funktioniert. Anders kann ich es mir nicht erklären, dass es Stand heute genau eine IDE gibt, die meine Anforderungen erfüllt. Dabei lassen die sich an einer Hand abzählen:

  • Syntax-Highlighting und Code Completion für Python
  • Integrierte Unterstützung für Git
  • Lauffähig unter Linux, FreeBSD und Solaris

Es gibt zwar unzählige Editoren, die Syntax-Highlighting können – an Code Completion scheitern jedoch (fast) alle Kandidaten, insbesondere an projektinternen Verweisen und Bezeichnern. Aptana's PyDev hatte ich für einige Projekte eingesetzt – allerdings funktioniert Eclipse unter FreeBSD nur bedingt, und PyDev verheddert sich regelmäßig mit import-Anweisungen. Für Projekte, die ich zwingend unter FreeBSD entwickeln und testen muss, keine gute Voraussetzung – da funktioniert jeder normale Texteditor genauso gut oder schlecht.

NetBeans war auf einem richtig guten Weg (wenn man von den Farben für's Syntax-Highlighting mal absieht), und lief auf problemlos auf allen erforderlichen Plattformen. Nur leider hat Oracle der Python-Unterstützung den Garaus gemacht – seit Version 7 gibt es keine Python-Unterstützung mehr. Zwar soll Python für NetBeans angeblich als Community-Projekt weiterleben, bisher ist von funktionierendem Code allerdings nicht viel zu sehen.

Bleiben noch KDevelop und Anjuta, wenn man den Blick mal auf die Open Source Welt beschränkt. KDevelop hat (mittlerweile) eine gute Git-Unterstützung; an Python wird jedoch noch gearbeitet (siehe Playground). Anjuta kann zwar Python und Git (wobei auch hier Code Completion noch eine ziemliche Baustelle ist), versaut Python-Projekte aber mit seiner Autotools-Sucht (was haben die bitteschön bei einem Python-Projekt zu suchen?). Außerdem zerrt Anjuta unter FreeBSD die gesamten rottigen Gnome-Ports als Abhängigkeit hinter sich her – unschön, weil oft auf Wochen das System wieder nicht aktualisiert werden kann, wenn einer dieser Ports mal wieder eine Macke hat (einer der Gründe, warum ich unter FreeBSD wieder zu KDE zurück gewechselt bin).

Für den produktiven Einsatz muss man unter'm Strich wohl sagen, dass es keine wirklich geeignete Open Source IDE gibt, die für meine Zwecke einsetzbar wäre. Aber auch bei den kommerziellen Vertretern wird es dünn: Wing und Komodo laufen nur mit ach und krach unter FreeBSD (sind aber ansonsten gute IDEs); außerdem schrecken beide mit (zu) hohen Lizenzkosten (zumindest für jemanden wie mich, der mit seinem Code keine großen Umsätze macht).

Schlussendlich arbeite ich momentan mit JetBrains PyCharm. Die IDE ist in Java geschrieben und läuft ootb unter FreeBSD. Zur Zeit gibt's auf die Lizenzen 50% Rabatt, so dass die (ohnehin recht günstige) Lizenz für mich noch erschwinglicher wurde. Optisch ist die IDE zwar nicht so ansprechend, aber die „inneren Werte“ sind recht überzeugend: Git und sogar GitHub werden unterstützt, und die Code-Indizierung ermöglicht Code Completion vom feinsten. Allerdings ist die IDE ein bisschen lahm – die Bedienung fühlt sich zäh an (das habe ich bei anderen Java-GUI-Anwendungen auch schon besser gesehen), und der Speicherverbrauch ist enorm. Damit kann ich aber leben, zumal es leider derzeit keine attraktive Alternative gibt.

No comments | Defined tags for this entry: IDE, open source, python

Pretty Hard to Protect

Posted by Jesco Freund at Dec. 14, 2010 10:52 p.m.

Unter diesem Titel hatte schon Captain Crunch anno 2006 einen recht bissigen, aber treffenden Artikel zu PHP geschrieben. Wirklich gebessert hat sich seither nichts – wenn pro Version (nach über einem halben Jahr) gefühlte 10 Vulnerabilities gefixt werden (siehe Release-Announcement für 5.3.4), zeugt das nicht von hohem Sicherheitsbewusstsein der PHP-Entwickler, sondern schlicht von miesem Qualitätsmanagement.

Die zahlreichen kritischen Bugs treten übrigens (fast) ausschließlich in den Extensions auf. Das legt für mich den Schluss nahe, dass der Ansatz, alle (Zusatz-) Funktionalität in (in C geschriebenen) Extensions zu organisieren, unter Qualitätsaspekten vielleicht nicht der beste ist. Andere Interpreter-Sprachen wie Perl oder Python konzentrieren sich bei der Programmierung mit C auf den Interpreter-Kern und lagern Zusatzfunktionalität in Module aus, die in der jeweiligen Interpretersprache selbst geschrieben sind.

So können diese auch von weniger erfahrenen Programmierern entwickelt und maintained werden – in Python oder Perl (oder auch PHP) selbst ist es einfach schwierig bis unmöglich, eine NULL pointer dereference oder einen Buffer Overflow zu provozieren. Dazu bedürfte es schon eines Bugs im Interpreter, dessen Code aber verhältnismäßig übersichtlich ist und daher einigermaßen gut auditiert werden kann.

Die ziemlich schlechte Qualität der PHP-Extensions ist meiner Meinung nach ein Stück weit dem Entwicklungsmodell geschuldet – Besserung ist daher erst zu erwarten, wenn hier ein Umdenken seitens der tonangebenden PHP-Entwickler stattfindet. Das ist allerdings derzeit nicht erkennbar…

No comments | Defined tags for this entry: Perl, PHP, programming, python, security

Python für Webanwendungen 4: Lieferservice

Posted by Jesco Freund at Oct. 29, 2010 9:56 p.m.

Seit dem vorherigen Teil hat es nun ein paar Tage gedauert - aber hier ist er nun, der versprochene letzte Part. Eine funktionierende Webanwendung ist nun vorhanden, aber noch läuft sie nur im Entwicklungsmodus, mit dem CherryPy-eigenen Webserver. Für eine Produktivumgebung ist definitiv ein gestandener Webserver vorzuziehen, der den statischen Content besser und schneller ausliefert, robust und praxiserprobt ist und sich über entsprechende Startmechanismen automatisch als Dienst starten lässt.

Mit WSGI-Anwendungen und FastCGI hatte ich bisher kein Glück – zu instabil lief dieses Konstrukt, wenn es überhaupt ans Laufen kam. Richtig schnell und robust hingegen laufen bei mir diverse WSGI-Anwendungen in Kombination mit dem Apache Webserver und mod_wsgi. Unter FreeBSD beispielsweise lassen sich beide Pakete bequem aus den Ports installieren, auch Debian bringt ein entsprechendes Paket mit.

continue reading Python für Webanwendungen 4: Lieferservice

1 comment | Defined tags for this entry: Apache, CherryPy, code, development, python

Python für Webanwendungen 3: Türsteher

Posted by Jesco Freund at Oct. 26, 2010 11:29 a.m.

Mit ein wenig Phantasie kann die Anwendung aus Teil 2 hübsche HTML-Seiten rendern und verschiedene Themes verwenden. Doch was, wenn eine dieser Ansichten vor unbefugten Augen geschützt werden soll? Sicher, CherryPy bringt eine rudimentäre Authentifizierung über HTTP-Auth mit – keine sehr elegante Lösung. Von einer modernen Webanwendung erwartet man eher ein Login-Formular.

Das wäre mit einem hübschen Template und einer Controller-Methode ja noch fix erledigt. Doch wogegen authentifiziert eine Anwendung eigentlich? Viele Webanwendungen haben die in meinen Augen sehr schlechte Angewohnheit, auf eine eigene Userverwaltung zu bauen. Als Backend kommen häufig Datenbank-Tabellen in einem RDBMS zum Einsatz. Ich finde das äußerst nervig, denn i. d. R. lassen sich diese User-Informationen nicht oder nur mit aufwändigen Hacks von anderen Anwendungen nutzen – mit der Konsequenz, dass User für jede Applikation ein eigenes Login-Handle benötigen.

Sowohl für User als auch Admin ist es viel angenehmer, wenn jedem User (z. B. in einem Unternehmen, einer Organisation, einer Community, …) genau ein Handle zugeordnet ist. Nur ein Passwort, das vergessen werden kann, Änderungen von Attributen (Nickname, Name, Mail-Adresse, …) schlagen in allen Anwendungen durch, und als Admin muss man sich nur mit einer Userdatenbank herumschlagen. LDAP bietet genau diese Möglichkeit: Alle User-Handles an einem Ort zu speichern, und diese mit zusätzlichen Attributen auszustaffieren - je nachdem, was die verschiedenen Anwendungen so benötigen. Auch der Zugriff auf einzelne Anwendungen oder Anwendungsbereiche lässt sich über LDAP-Gruppen regeln.

In diesem Teil geht es daher um die Implementierung eines eigenen Authentifizierungs-Moduls für unsere Webanwendung, das gegen einen LDAP-Verzeichnisdienst authentifiziert. Um das Beispiel erst mal nicht zu komplex gestalten, soll das Modul nur die übergebenen Credentials prüfen, um den Zugang zur Applikation zu erlauben oder zu verwehren. Komplexere Prüfungen (etwa die Zugehörigkeit zu einer bestimmten LDAP-Gruppe) lassen sich dann später leicht einbauen.

continue reading Python für Webanwendungen 3: Türsteher

No comments | Defined tags for this entry: CherryPy, code, development, Genshi, python

Python für Webanwendungen 2: Genshifizierung

Posted by Jesco Freund at Oct. 25, 2010 4:34 p.m.

Die im vorhergehenden Teil vorgestellte Anwendung ist in ihrem Können bisher eher sparsam – keine großartige Anwendungslogik, keine komplexe Steuerung, keine hübsche Darstellung. Genau diesem letzten Askpekt möchte ich mich im zweiten Teil der HowTo-Serie zu Python und Webanwendungen widmen. Für Webanwendungen (fast) unumgänglich ist die Darstellung der Oberfläche mittels (X)HTML. Die finsteren Zeiten, in denen man sich in CGI-Anwendungen das HTML-Dokument noch mittels print() zusammengebaut hat, sind glücklicherweise längst vorbei.

Heute benutzt man dafür Template-Systeme. Grundsätzlich lassen sich Template-Systeme in drei Kategorien einteilen:

  1. Als Platzhalter-Templates bezeichne ich Template-Systeme, die darauf beruhen, in einem (wie auch immer gearteten) Template-Dokument auf bestimmte Weise gekennzeichnete Platzhalter auszutauschen. Die Verarbeitung dieser Templates basiert meist auf Regulären Ausdrücken oder auf einfachen Suchen/Ersetzen-Operationen.
  2. XML-Templates würde ich Templates nennen, die einen eigenen XML-Namensraum definieren und dadurch dem xhtml-Namensraum im selben Dokument nicht in die Quere kommen. Die Verarbeitung erfolgt über einen XML-Parser, Xpath und ggf. XSLT-Transformationen.
  3. Kompilierte Templates kenne ich eigentlich nur aus einem Bereich, und hier stellen sie für mich einen Sonderfall der XML-Templates dar. Das Template wird beim Start der Applikation geladen und in eine Controller-Funktion umgewandelt, die aus den im Template eingebetteten Code-Schnipseln und print()-Anweisungen für die HTML-Dekoration besteht.

Für Python steht eine Reihe von fertigen Template-Systemen aus den Kategorien Platzhalter- und XML-Templates zur Verfügung. Gerade bei arbeitsteiliger Entwicklung bietet sich der Einsatz eines XML-Template Systems an. Auch wenn man sich dadurch zunächst etwas mehr Komplexität einhandelt – die höhere Flexibilität macht das in großen Teilen wieder wett. Aus dieser Überlegung heraus kommt in der Beispielanwendung das Template-System Genshi zum Einsatz.

continue reading Python für Webanwendungen 2: Genshifizierung

No comments | Defined tags for this entry: CherryPy, code, development, Genshi, python

Python für Webanwendungen 1: Projektstruktur

Posted by Jesco Freund at Oct. 25, 2010 1:03 p.m.

Hier nun wie angedroht der erste Teil, in dem ich einmal vorstellen möchte, wie man sich selbst basierend auf CherryPy und Genshi das Grundgerüst für eine Webanwendung aufbaut. Dabei geht es mir jedoch nicht um's Wiederkäuen der Dokumentation (wie etwa des Genshi Tutorials) – die darf jeder schön selber lesen ;-). Vielmehr geht es mir darum, ein Grundgerüst zu beschreiben, das eine belastbare Basis auch für komplexere Anwendungen darstellt. Das kommt IMHO in der angebotenen Dokumentation einfach zu kurz – ein „Hello, World“ mit dem gesamten Code in einer einzigen Python-Datei ist sicherlich kein Best Practice für die Entwicklung von Webanwendungen…

Zunächst einmal möchte ich kurz darauf eingehen, warum ich CherryPy und Genshi gewählt habe. Bei Genshi liegt der Fall relativ einfach: In meinen Augen ist es die derzeit mächtigste und professionellste Framework-unabhängige Template Engine, die für Python zu haben ist. Anders als bei vielen anderen Template-Engines üblich verwendet Genshi einen eigenen XML-Namensraum, so dass Templates während der Entwicklungsphase als ganz normale XHTML-Seiten behandelt werden können – für Designer und HTML-Bastler ein großes Entgegenkommen.

Bei CherryPy liegen die Pro's und Con's dichter beieinander. Auf der einen Seite bringt CherryPy schon Funktionalität mit, die ich eigentlich gar nicht haben will. Auf der anderen Seite ist CherryPy ein aktiv entwickeltes und gepflegtes Projekt, und genau die Dinge, die ich benötige, bringt es ebenfalls mit: WSGI-Fähigkeit, eine einfache Schnittstelle zum Request, URL-Mapping und Sessions. Als zusätzlicher Leckerbissen bringt CherryPy auch noch eine eigene Konfigurations-Engine mit und bietet mit der Tools-Schnittstelle ein zugleich einfaches und mächtiges Werkzeug für eigene Erweiterungen. Eine Alternative wäre gewesen, Flup als WSGI-Basis zu verwenden und URL-Mapping, Sessions und Request-Handling selbst zu implementieren. Die Wahrscheinlichkeit, dabei Bugs und ggf. eine Angriffsfläche gleich mit einzubauen, halte ich jedoch für relativ hoch – daher meine Entscheidung für CherryPy.

continue reading Python für Webanwendungen 1: Projektstruktur

No comments | Defined tags for this entry: CherryPy, code, development, Genshi, python

Python für Webanwendungen: Einführung

Posted by Jesco Freund at Oct. 25, 2010 12:49 p.m.

Django ist derzeit eines der mächtigsten RAD-Frameworks für's Web. Genau wie seine Konkurrenten (Ruby on Rails, Pylons, TurboGears & Co.) ist Django jedoch sehr stark auf Anwendungsfälle fixiert, in denen Datensätze in bzw. aus einem RDBMS angelegt, bearbeitet, angezeigt und gelöscht werden. In anderen Anwendungsfällen dominiert heute Java – wirklich gerechtfertigt ist das aber nicht.

Gerade Python macht es einem Entwickler dank WSGI und einer Vielzahl nützlicher Bibliotheken sehr leicht, sein eigenes Framework zusammenzusetzen. Dabei beziehe ich mich mit „Framework“ auf eine bestimmte Strukturierung der Anwendung, durch die Standard-Aufgaben (wie etwa das Rendern von HTML-Seiten) extrem einfach zu implementieren sind. Da ein ganzes Framework zu viel für einen einzelnen Blog-Eintrag ist, habe ich dieses HowTo in vier Stücke zerhackt:

  1. Aufbau einer Projektstruktur
  2. Integration von Genshi
  3. Authentifizierung gegen LDAP
  4. Deployment in einer Produktivumgebung

Zu guter Letzt noch ein kleiner Hinweis: Meine Code-Beispiele beziehen sich auf Python 2.7 – daher ist bei älteren Versionen (insbesondere <2.6) Vorsicht geboten. Gerade wenn Exceptions ins Spiel kommen, halte ich mich an die neue as-Notation gemäß PEP 3110.

No comments | Defined tags for this entry: CherryPy, code, development, Django, Genshi, python, TurboGears

Die Rückkehr der Primzahl

Posted by Jesco Freund at Sept. 2, 2010 9:16 p.m.

Vor über einem Jahr hatte ich mal über einen kleinen Wettstreit bezüglich eines Primzahl-Generators gebloggt. Damals hatte ich mich darauf beschränkt, das Problem durch geschickte Partitionierung des zu testenden Intervalls zu parallelisieren. Allerdings war meine Implementierung alles andere als perfekt und krankte vor allem an Pythons Global Interpreter Lock. Meine Freundin hatte mich mit ihrer Implementierung fast um Faktor 2 geschlagen :-(

Doch nun habe ich sie in Händen, die ultimative Waffe des Primalitätstesters: im Zen Python Blog ist die Implementierung des Miller-Rabin-Tests in Python wunderbar beschrieben und erklärt. Dieser Test ist probabilistisch; nach unseren Spielregeln muss also bei einem positiven Treffer auf jeden Fall ein deterministischer Test (Primfaktorzerlegung) durchgeführt werden. Allerdings liefert Miller-Rabin verhältnismäßig wenige False Positives, so dass sich mit Hilfe dieses Tests das Finden von Primzahlen noch deutlich beschleunigen lassen sollte.

No comments | Defined tags for this entry: algorithms, programming, Project Euler, python

Go: First Contact

Posted by Jesco Freund at May 8, 2010 12:38 a.m.

Und wieder ist die Welt um eine Programmiersprache reicher geworden – die Rede ist von Go, einer unter Schirmherrschaft von Google entwickelten Sprache, zu deren Vätern auch Vertreter der Unix-Prominenz (wie etwa Ken Thompson) gehören. Auch wenn einige „Fach“-Journalisten (mal wieder) die Sensation wittern und bereits die Totenglocken für C, C++ und Java läuten hören, habe ich mal (entgegen meiner Gewohnheit, bei journaille-generierten Hypes aktiv wegzusehen) ein bisschen mit Go herumgespielt, um mir ein eigenes Urteil erlauben zu können.

Auf den ersten Blick wirkt die Sprache ein bisschen wie „OK, wir nehmen C, fügen Objektorientierung hinzu, ohne die Komplexität von C++ ertragen zu müssen, und packen noch ein bisschen Nebenläufigkeit dazu“. Auf den zweiten Blick offenbart sich, dass die Sprache offenbar einer Hippie-Kommune entsprungen ist – jedenfalls lässt sich nicht mehr so genau sagen, wer die eigentlichen Eltern sind ;-). C und C++ haben auf jeden Fall Pate gestanden (bei Ken & Co. auch nicht anders zu erwarten), aber auch Elemente von Java, Python und sogar Pascal sind mit eingeflossen.

continue reading Go: First Contact

2 comments | Defined tags for this entry: C, Go, google, programming, python

Page 1 of 3 next page »