GIL removal in Python 1.4

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Die Frage ist halt, wie man bei einer Programmiersprache bei der Weiterentwicklung vorgehen will. Python3 ist sicherlich keine Revolution, aber dafür ist es eben möglich halbwegs einfach von 2 nach 3 zu portieren. Zudem darf man bei einer Sprache eines nicht vergessen: Die muss verdammt Bug frei sein; ich liebe zwar meinen KDE Desktop, aber selbst da tat der Bruch beim Umstieg auf die 4er Version schon weh zu Beginn. Und da haben die so ziemlich alles umgekrempelt, was es an technischer Basis gab. Die Philosophie ist geblieben. Ginge so etwas aber wirklich bei einer Sprache? Kann man da so revolutionär vorgehen?

Klar wäre es toll, wenn Python3 für Multicore Rechner out of the box skaliert. Aber wenn man dafür die Sprache im Kern ändern müsste, wäre es für viele wohl kein "Python" mehr. (Kann aber sein, dass ich diesen technischen Kram rund um den GIL hier nicht verstanden habe - das ist mir (noch) zu tief ;-) )

Ich vermute mal, dass Guido und Konsorten eben genau so ein "Mittelding" aus tiefergreifenden Änderungen und Konstanz wollten. Vermutlich gibt es keinen optimalen Weg, es allen Recht zu machen ;-)
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

snafu hat geschrieben:Meint ihr, es wäre - im Nachhinein betrachtet - besser gewesen, wenn man für Python 3 mehr Wert auf Abwärtskompatibilität gelegt hätte?
Jein es gibt zwei Möglichkeiten, entweder so kompatiblel, dass ein 2to3.py fast immer funktioniert. Oder noch inkompatibler, dass sich der Umstieg lohnt.

Ene Möglichkeit wäre da z.B. die Veränderung des Objektmodells, dass Python leichter zu optimieren geht, z.B. wie von sma vorgeschlagen Attributzugriffe generell durch Methodenaufrufe zu ersetzen wie in self. Und man sollte vielleicht das __dict__ loswerden. Damit gibt man auch nicht allzu viel Flexibilität auf die ObjC 2.0 runtime zeigt.

Eventuell wären echte Blöcke eine Überlegung wert.

Was Python 3 auf jeden Fall gut getan hätte ist das auch schon von sma angesprochene neue GUI-Toolkit. Ich will nicht immer 100er MB qt-Bibliotheken installieren um eine gute GUI zu bekommen. Ein ctypes-Layer über Win32, Qt und Cocoa wäre nett. Evtl. sowas: http://wiki.python.org/moin/PyGUI
Antworten