Das Python Insider-Team freut sich heute zwei neue Blogs anzukündigen. Übersetzer für Rumänisch und Chinesische Kurzzeichen sind dem Übersetzungsprojekt beigetreten und haben schon damit angefangen die aufgelaufenen Posts zu veröffentlichen. Wie auch die anderen Übersetzungen, werden diese Übersetzungen den Posts auf Python Insider etwas hinterherhinken.
Samstag, 30. Juli 2011
Übersetzungen ins Portugiesische, Deutsche, Koreanische und zu Chinesischen Langzeichen
Das Python Insider Übersetzungsprojekt wächst weiter! Heute starten wir die Portugiesische, Deutsche, Koreanische und die Chinesische Langzeichen Version des Blogs. Die Übersetzer haben schon damit angefangen die aufgelaufenen Posts zu veröffentlichen und wie auch die anderen Übersetzungen, werden diese Übersetzungen den Posts auf Python Insider etwas hinterherhinken.
Mittwoch, 27. Juli 2011
Jython migriert zu Mercurial
Jython ist endlich von Subversion zu Mercurial migriert. Dies lief schon seit einiger Zeit, aber unglücklicherweise hatten wir ein schwieriges Subversion-Repository, darum war einiger Aufwand nötig, um es sauber zu einem anderen Versionskontrollsystem zu konvertieren.
Das neue offizielle Jython-Repository ist nun bei
beheimatet, zusammen mit einem BitBucket Mirror zum einfachen forken.
Es gibt auch ein größeres Repository mit laufenden Feature-Zweigen (zu Mercurial Bookmarks konvertiert) bei http://hg.python.org/jython-fullhistory , das aber nur lesbar ist.
Mercurial macht es sogar noch leichter an Jython mitzuarbeiten: Forke das Repository und hilf uns Jython 2.6 zu bauen!
Samstag, 23. Juli 2011
Python 3.3 wird Unterstützung für OS/2, Windows 2000 und VMS einstellen
Hin und wieder ist es an der Zeit die Liste der unterstützten Betriebssysteme so zurückzuschneiden, dass sie mit der tatsächlichen Benutzung übereinstimmt. Daneben ist auch die Menge der beisteuernden Entwickler auf einer Plattform wichtig, da jemand die Entwicklungsarbeit leisten muss, um beim Release die Qualität zu sichern. Andere Faktoren, wie das Alter eines Betriebssystems und sein Ballast für die zukünftige Entwicklung haben auch einen Einfluss auf diese Liste.
Victor Stinner hat kürzlich vorgeschlagen die Unterstützung von CPython für OS/2 und VMS einzustellen, ein Jahr nach seiner ursprünglichen Frage nach der OS/2-Unterstützung. Victors ursprüngliche Frage kam zur Zeit seiner unermüdlichen Unicode-Arbeit, genauer für ein Problem mit os.execvpe(), um Umgebungsvariablen über den PEP 383-"surrogateescape"-Handler zu unterstützen. OS/2 und VMS haben zur Zeit keine Repräsentation innerhalb des Entwicklerteams und erhalten damit keine Tests während dem Release-Prozess.
Das Schreiben dieses Eintrags brachte mich zum Nachdenken über eine vorherige Diskussion über das Entfernen von Windows 2000, das auf der Strecke zu bleiben schien. System, die COMSPEC auf command.com setzen, schienen damals auch auf dem Hackbrett zu liegen. Mittlerweile haben sich beide zu OS/2 und VMS gesellt. Windows 2000 wird entfernt, um die Entwicklungsarbeit einfacher zu machen, da es die Last nimmt, sich um die Legacy-API eines Betriebssystems zu kümmern, das 2010 sein "end-of-life" erreicht hat.
Um die Unterstützung für diese Systeme zu entfernen, haben Victor und ich uns daran gemacht PEP 11 zu aktualisieren.
PEP 11
Dieses PEP umreißt die Betriebssysteme, die nicht mehr unterstützt werden, und erklärt wie man ein System zu dieser Liste hinzufügt.
Sobald es entschieden ist, dass ein Betriebssystem entfernt werden kann, wird es formal als nicht-unterstützt angekündigt. Diese Ankündigung gilt traditionell für die Version, an der gerade entwickelt wird, also gilt der Wegfall der Unterstützung für OS/2, Windows 2000 und VMS ab Python 3.3.
Das erste Stadium läuft so ziemlich von selbst, es ist mehr das Heben einer weißen Flagge. Es ist ein Signal, dass es keinen mehr gibt, der den Code wartet und die Qualität eines Release sicherstellt. Es können Veränderungen am Kompilierungs- und Installationsprozess gemacht werden, um Nutzer zu informieren, dass ihre Plattform nicht unterstützt wird. Und dem "What's New"-Dokument wird eine Bemerkung hinzugefügt, die die neuen nicht mehr unterstützten Plattformen auflistet.
Nach einem Releasezyklus, in dem die Plattform nicht unterstützt ist, ist der Code in der nachfolgenden Version Freiwild und kann entfernt werden. In diesem Fall kann der Code in 3.4 entfernt werden. Der Code wird möglicherweise nicht komplett entfernt, aber Entwickler, die während ihrer normalen Arbeit daran vorbeikommen können jegliche #ifdef-Blöcke, configure-Abschnitte oder veralteten Code entfernen.
Was Du tun kannst
Wenn du ein OS/2- oder VMS-Nutzer bist, dann gibt es ein paar Möglichkeiten, die du ausschöpfen kannst, um deine Plattform zu retten.
Werde Maintainer
Nichts ist besser für die Unterstützung als ein aktiver Entwickler. Andrew MacIntyre war seit einiger Zeit der OS/2-Maintainer und sagte zu Victors erster Anfrage, dass OS/2 in der Unterstützung von Unicode hinterherhinkt, dies ist also sicherlich ein Gebiet auf das man sich konzentrieren muss. VMS scheint einen gewissen Grad von Unterstützung von Außen durch http://www.vmspython.org zu haben, aber wie schon in Issue 11918 diskutiert wurde, muss sich jemand bereiterklären um weiterhin VMS-Unterstützung Upstream (d.h. innerhalb von CPython) zu haben.
Wenn Du daran interessiert bist, eine der beiden Plattformen zu übernehmen, dann schau dir den Developer's Guide an, um die aktuellen Entwicklungsprozesse kennenzulernen.
Steuer einen Build-Slave bei
Mit einem aktiven Entwickler, hat eine Plattform bessere Chancen zu überleben. Mit einem Build-Slave, hat eine Plattform sogar noch bessere Chancen, nicht nur zu überleben, sondern auch um eine gewisse Qualität zu gewährleisten.
Python benutzt Buildbot für Continuous Integration und es gibt momentan Build-Slaves für Linux, Mac, Windows und Open Indiana (Solaris) für verschiedene Versionen, Architekturen und Konfigurationen. Wenn Du in der Lage bist eine Maschine für die Build-Flotte für OS/2 oder VMS zu spenden, könntest Du ermöglichen, dass diese Plattformen diesselbe Aufmerksamkeit bekommen, wie sie auch verbreitetere Plattformen bekommen.
Wenn Du entwender Zeit oder Hardware beisteuern kannst, um OS/2 und VMS zu retten, melde Dich auf der python-dev-Mailingliste, um die Bemühungen zu koordinieren.
Sonntag, 17. Juli 2011
Python Insider Übersetzungsprojekt
Wir denken, dass der Inhalt dieses Blogs für die gesamte Python-Community nützlich ist, darum hat für uns das Erreichen möglichst vieler Leser eine hohe Priorität. Um unsere Reichweite zu erhöhen, haben wir ein Team von Übersetzern um uns geschart, damit wir parallel Ausgaben dieses Blogs in anderen Sprachen erstellen können. Heute starten wir zwei Übersetzungen: Japanisch und Spanisch.
Die Übersetzungen werden den Posts auf Python Insider etwas hinterherhinken, aber es wird versucht sie mehr oder weniger aktuell zu halten.
Hilfe gesucht
Das Übersetzungsteam ist immer noch sehr klein, darum suchen wir nach weiteren Helfern. Wir brauchen Leute, die an den bestehenden Übersetzungen arbeiten oder uns helfen neue Übersetzungen zu starten. Wenn Du uns auf eine dieser Arten helfen kannst, kontaktiere Doug Hellmann (doug dot hellmann at gmail -- englischsprachig).
Meet the Team: Brian Curtin
Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.
| Name: | Brian Curtin |
|---|---|
| Standort: | Chicago, USA |
| Homepage: | http://blog.briancurtin.com/ |
Wie lange nutzt Du schon Python?
Täglich seit 6 Jahren. Davor nutzte ich Python schon gelegentlich für eine Klasse im College und in einem Sommer-Praktikum.
Wie lange trägst Du schon zum Kern bei?
Knapp über ein Jahr. Am 24. März war ich ein Jahr bei der Gruppe.
Wie wurdest Du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?
Ich habe angefangen, nachdem ich einen Fehler in der Dokumentation bemerkt habe, als ich auf der Arbeit ein Erweiterungsmodul geschrieben habe, dann habe ich einen einfachen Patch eingereicht und Georg Brandl hat ihn fast augenblicklich aufgenommen. Nach diesem schnellen Erfolg und nachdem ich mir eine frische Version des Quellcodes geholt habe, wollte ich eintauchen und mehr über die Module lernen, die ich benutze, und endete damit einen Patch zu schreiben, der zipfile "context manager"-Unterstützung hinzufügt.
Meine ersten Paar Beiträge waren Ausbesserungen der Dokumentation, um es für den Anfang einfach zu halten. Mein erster Quellcode-Beitrag fügte dem winreg-Modul ein paar Features hinzu und erweiterte die Test-Abdeckung.
An welchen Teilen von Python arbeitest Du jetzt?
Als einer der paar Windows-Benutzer, die bei der CPython-Entwicklung beteiligt sind, versuche ich ein Auge auf alle Probleme zu haben, die Windows-Benutzer betreffen. Deshalb hatte ich schon Gelegenheit an vielen Modulen der Standardbibliothek zu arbeiten, unter anderem Modulen, die ich noch nie benutzt habe. Ich habe noch nicht viel am Interpreter selbst gearbeitet, aber ich versuche das zu ändern.
Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?
Ich baue verschiedene Test-Werkzeuge für eine Handels-Datenbank, die in C++ geschrieben ist. Dort gibt es ein Erweiterungsmodul für die Daten-API, sodass wir einfach Regressionstests und Leistungstests schreiben können und wir versuchen immer mehr zu bauen.
Was macht Du, wenn Du nicht gerade programmierst?
Ich bin ein riesiger Baseball-Fan. Im Frühling bin ich Schiedsrichter bei College-Baseball, im Sommer bei verschiedenen Ligen und dann schaue und gehe ich zu Spielen der Chicago Cubs.
Donnerstag, 14. Juli 2011
Meet the Team: Nick Coghlan
Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.
| Name: | Nick Coghlan |
|---|---|
| Standort: | Brisbane, Australien |
| Homepage: | http://www.boredomandlaziness.org |
Wie lange nutzt Du schon Python?
Mein erster Kontakt war etwa 1999 mit 1.5.2, als unser Dozent Python für einen Kurs über Netzwerke nutzte. Professionell startete ich etwa 2002 mit 2.2 für automatisierte Tests und habe es nie bereut.
Wie lange trägst Du schon zum Kern bei?
Guido gewährte mir Zugang in 2005, um PEP 343 (vor allem, um die context-Methode loszuwerden) zu aktualisieren.
Wie wurdest Du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?
Was das Beitragen von Patches angeht, hatte ich 2004 drei Monate frei und verbrachte viel Zeit davon zusammen mit Raymond und Facundo mit der Arbeit am decimal-Modul, vor allem mit dem laufen lassen des telco-Benchmarks, um den Code schneller zu machen. Ein paar der seltsameren Hacks im decimal-Modul (wie die Abkürzung für das Überprüfen auf Sonderfälle und die Benutzung von Strings beim Umwandeln von Tupeln in Integer) stammen aus dieser Zeit.
Mein wirklich erster Commit war dann wohl zu PEP 343 und danach wahrscheinlich zum AST-Compiler-Zweig als wir ihn für die Aufnahme in 2.5 fertig machten.
An welchen Teilen von Python arbeitest Du jetzt?
runpy, functools und contextlib sind die Hauptsachen, die letztendlich in meinem Posteingang landen. Ich beobachte auch aufmerksam, was Brett und Victor mit import tun, was Raymond mit collections und itertools tut und alles was mit dem Compiler passiert. Auch fasziniert mich der kulturelle Aspekt der Dinge.
Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?
Wirklich keine große Sache. Der Python-Kram auf der Arbeit leistet normalerweise einfach seine Arbeit, darum gibt es momentan keinen großen Bedarf daran zu arbeiten. Ich will etwas schaffen, das meine digitale Musiksammlung aufräumt, aber die Skripte, dafür sind momentan nur schnell zusammengeworfen.
Was macht Du, wenn Du nicht gerade programmierst?
Tae kwon do, Computerspiele, Fußball, Lesen, etc, etc...
Sonntag, 10. Juli 2011
Neues Blog Design
Falls Du den Python Insider (oder die deutsche Übersetzung) über einen Feed-Reader liest, hast Du vielleicht das neue Design noch nicht bemerkt, das Marcin Wojtczuk für uns erstellt hat. Es sieht toll aus, erhält aber trotzdem ein leichtgewichtiges Lesegefühl und wir könnten nicht glücklicher mit den Ergebnissen sein.
Marcin: Danke für deine Zeit und Mühe!
urllib/urllib2 Sicherheitslücke behoben
Guido van Rossum hat kürzlich einen Fix für CVE-2011-1521 gepusht, das ein Sicherheitsproblem in den URL-Bibliotheken von Python beschreibt. Obwohl Sicherheitslücken selten sind, ist dies eine gute Gelegenheit, um über den Prozess hinter dem Berichten, Behandeln und Beheben von Problemen zu informieren, wenn sie denn entstehen.
Problem berichten
Wenn Du eine Sicherheitslücke in CPython entdeckt hast, dann bitten wir Dich zuerst darum die Details vertraulich zu behandeln. Nachdem Du festgestellt hast, dass Du ein echtes Sicherheitsproblem gefunden hast, ist es am wichtigsten dein Wissen an die Kernentwickler weiterzugeben, indem Du einen prägnanten, aber detaillierten Bericht erstellst.
Ein guter Bericht erklärt, wie die relevanten Teile des Systems von dem Problem betroffen sind. Es ist auch hilfreich zu wissen, ob das Problem auf einer bestimmten Plattform oder wegen einer Abhängigkeit auftritt. Es ist nützlich die betroffenen Versionen zu wissen und es ist wahrscheinlich, dass alle aktuellen Releases auf die Schwachstelle hin überprüft werden. Zu guter Letzt: Wenn Du einen Testfall für das Problem hast, dann stelle sicher, dass Du ihn beifügst. Deinen Bericht solltest du an security@python.org schicken.
Niels Heinen vom Google Security Team hat kürzlich einen guten Bericht eingereicht. Er entdeckte ein Problem mit der HTTP 302-Umleitungsbehandlung in den urllib- und urllib2-Modulen der Standardbibliothek. Er fand heraus, dass ein Server Requests auf unpassende Schemata umleiten konnte und so Situationen erzeugten, die Systeme oder Daten kompromittieren könnten. In seinem ersten Bericht, erklärt Niels zwei Szenarien, in denen Weiterleitungen Probleme aufdecken könnten.
Da urlib/urllib2 einen Handler für das file:// URL-Schema anbietet, könnte eine Weiterleitung nach file:///etc/passwd Passwort-Daten preisgeben. Niels erklärte weiterhin, dass eine Weiterleitung auf ein Systemgerät wie file:///dev/zero zu Erschöpfung von Ressourcen und damit zu einem Denial of Service führen könnte.
Handhabung von Berichten
Aufgrund der sensiblen Natur von Sicherheitslücken, wird die security@python.org-Mailingliste von einer kleinen Gruppe vertrauenswürdiger Entwickler betreut, die Berichte analysieren und so schnell wie möglich auf sie reagieren. Wenn Du deine Kommunikation mit der Liste verschlüsseln willst, findest du auf der Security News-Seite die OpenPGP-Details.
Wenn die Gruppe feststellt, dass es wirklich eine Sicherheitslücke gibt, kann ein öffentlicher Fehlerbericht mit einem beigefügten Patch erstellt werden. In diesem Fall machte Guido van Rossum das Problem mit Issue #11662 öffentlich, inklusive erstem Patch.
Beheben des Problems
Guidos Patch schränkt die Weiterleitung auf die URL-Schemata http://, https:// und ftp:// ein. FTP-Weiterleitung wurde für akzeptabel befunden und es ist in der Tat eine häufige Weiterleitung: Spiegel-Server für Downloads leiten manchmal an geographisch passende FTP-Server weiter.
In Python 2.x verursacht die redirect_internal-Methode von FancyURLopener nun einen IOError, wenn eine Weiterleitung an ein ungeeignetes Schema angefragt wird, genauso wie http_error_302 von HTTPRedirectHandler, nur ist es hier ein HTTPError. In Python 3 wurde urllib.request entsprechend repariert. Zusammen mit dem Patch gibt es zwei Tests, die sowohl die Weiterleitung zu passenden wie zu unpassenden Schemata testen.
Was die Weiterleitung an Nutzer angeht, so wird bald das letzte Sicherheits-Release von Python 2.5 veröffentlicht. Obwohl noch keine Termine für die Wartungszweige -- 2.6, 2.7, 3.1 und 3.2 -- festgelegt sind, bekamen alle den Code um die Lücke zu schließen.
Samstag, 9. Juli 2011
Meet the Team: Tarek Ziadé
Dieser Post ist Teil der "Meet the Team" Serie, die kurz das Python-Kernentwickler-Team vorstellen soll.
| Name: | Tarek Ziadé |
|---|---|
| Standort: | Turcey bei Dijon, Burgund, Frankreich |
| Homepage: | http://ziade.org |
Wie lange nutzt Du schon Python?
Rund zehn Jahre.
Wie lange trägst Du schon zum Kern bei?
Seit dem 21. Dezember 2008.
Wie wurdest Du Kernentwickler? Erinnerst Du dich an deinen ersten Beitrag?
Ich wurde Kernentwickler, um Distutils zu warten und weiterzuentwickeln.
Mein erster Beitrag als Kernentwickler war ein Fix für einen kleinen Bug eines distutils-Feature, den ich vorgeschlagen habe bevor ich Committer wurde. Dieses Feature wurde in der vorigen Woche Python hinzugefügt. Es ist die Möglichkeit die register und upload Befehle von Distutils zu konfigurieren, damit sie mit anderen PyPI-artigen Servern zusammenarbeiten.
Ich committete mit meinen brandneuen Rechten am Mittwoch, den 24. Dezember 2008, der zufällig auch mein Geburtstag und der 17. Jahrestag des 0.9.4-Release von Python.
An welchen Teilen von Python arbeitest Du jetzt?
In der Standardbibliothek: sysconfig, distutils, packaging (kommt mit Python 3.3), shutil, pkgutil und gelegentlich an anderen Modulen.
Was machst Du mit Python, wenn Du nicht gerade am Python-Kern schraubst?
Ich arbeite bei Mozilla im Service Team, wo ich Web-Dienste mit Python baue.
Was macht Du, wenn Du nicht gerade programmierst?
Ich lese Comics/Graphic Novels, schreibe Bücher, spiele mit meinen Kindern, trinke Wein mit meiner Frau und versuche mein 1848-er Haus zu renovieren.
Samstag, 2. Juli 2011
Formalisierung der AST-Change-Control-Policy
Python legt mit dem AST-Modul einen abstrakten Syntaxbaum (abstract syntax tree -- AST) offen, der die kompilierte Form von Python-Quellcode darstellt. Das AST-Modul erlaubt Nutzern Code anhand der AST-Darstellung, zwischen Parsing des Quellcodes und der Kompilierung zu Bytecode, zu inspizieren und zu verändern.
Die Bedeutung von Python-Code ist in der Sprachreferenz definiert. Das AST-Modul ist ein CPython-Implementierungsdetail und andere Python-Implementierungen müssen es nicht implementieren.
Kompatibilität des AST
Als Teil der Arbeit CPythons Peephole-Optimierer umzuschreiben, sodass er auf dem AST arbeitet (anstatt auf dem rohen Bytecode, wie es momentan der Fall ist), musste Eugene Toder einige Änderungen an der Struktur des AST machen. Als CPython-Implementierungsdetail war es nicht sofort klar, ob die Richtlinie zur Rückwärtskompatibilität auch den AST betrifft. Also stellte Eugene die Frage auf python-dev. Ist es bei AST-Änderungen notwendig rückwärtskompatibel zu bleiben?
Der allgemeine Konsens war, dass Kompatibilität nicht nötig wäre. Das AST-Modul stellt eine Konstante, ast.__version__ bereit, die Nutzercode eine Möglichkeit bietet sein Verhalten der genutzten AST-Version anzupassen. Das wurde als ausreichend Kompatibilität für ein implementierungsspezifisches Modul angesehen.
Andere Python-Implementierungen
Tatsächlich haben sowohl Jython als auch IronPython darauf hingewiesen, dass ihre jeweiligen Implementierungen entweder ein kompatibles AST-Modul haben oder eines bereitstellen wollen. Trotzdem meinten sie nicht, dass deswegen der AST eingefroren werden sollte und sind damit glücklich, dass der AST inkompatibel geändert werden könnte, solange die ast.__version-Konstante geändert wird.
Es wurde auch angesprochen, dass eine vollständige Testsuite in test_ast.py anderen Implementierungen dabei helfen würden, sicherzustellen, dass ihre Implementierungen zu CPython kompatibel sind. Die Abdeckung von test_ast.py zu erhöhen würde sich gut als Projekt für jemanden eignen, der sich bei den Python-Interna engagieren will!
Was passiert als nächstes?
Der Patch, der die Diskussion lostrat, hat noch nicht in CPython Einzug gehalten. Also könnte möglicherweise gar nichts passieren. Aber, wenn es doch passiert, wird der AST sich inkompatibel ändern. Die ast.__version__-Konstante wird sich ändern, um das widerzuspiegeln und Nutzercode wird damit die Veränderungen bemerken, aber Änderungen werden nötig sein. Allgemeiner gesprochen wird dies die Art und Weise sein, wie AST-Änderungen in Zukunft gehandhabt werden.
Die Python-Entwickler sind interessiert zu erfahren, wie weit verbreitet die Nutzung des AST ist und wie viele Auswirkungen diese Handhabung haben wird. Wenn es Leser gibt, deren Code von der Änderung betroffen ist, so sind sie aufgefordert sich an der Diskussion auf python-dev zu beteiligen.
Abonnieren
Posts (Atom)