Was hälst du von Greenlets? Die müsste man zwar auch explizit verwenden (d.h. sie sind natürlich nicht in Python eingebaut), aber wäre damit nicht auch Nebenläufigkeit auf Mehrkernern möglich?sma hat geschrieben:Das Multiprocessing-Modul ist IMHO viel zu schwergewichtig.
GIL removal in Python 1.4
Da kann ich nur einen educated guess machen: Sie erlauben ein ähnliches Architektur-Modell wie Erlang, allerdings erlauben sie es nur und bringen es nicht mit und insbesondere bringt die gesamte Infrastruktur nichts mit. Ich glaube zudem, dass dies zu dem auch im GIL-Removal-Artikel angesprochenen Preis kommt, nämlich einer teuren Synchronisation. Wunder, so vermute ich daher, kann auch diese Python-Variante nicht vollbringen. CPython in eine Stackless-Variante umzupatchen scheint mir einfach nicht der richtige Weg zu sein. Aus dem Bauch heraus bin ich immer noch der Meinung, dass es besser wäre, eine minimale Python-ähnliche Lösung neu zu bauen (und ich weigere mich zuzugeben, unter NIH zu leiden).snafu hat geschrieben:Was hälst du von Greenlets?sma hat geschrieben:Das Multiprocessing-Modul ist IMHO viel zu schwergewichtig.
Stefan
-
deets
Noe. Greenlets sind ja genau *nicht* Threads oder gar Prozesse mit teurem Kontext-Switch, sondern im Grunde Co-Routinen. Also per Definition single-threaded.snafu hat geschrieben:Was hälst du von Greenlets? Die müsste man zwar auch explizit verwenden (d.h. sie sind natürlich nicht in Python eingebaut), aber wäre damit nicht auch Nebenläufigkeit auf Mehrkernern möglich?sma hat geschrieben:Das Multiprocessing-Modul ist IMHO viel zu schwergewichtig.
-
deets
@sma
Du sprichst von Erlang als Gegenentwurf zu Python mit dem GIL fuer multi-threading, oder verstehe ich dich da falsch? Wenn ja, dann ist das so nicht richtig: erlang hat eine Programmier-Abstraktion, die nach echter Nebenlaeufigkeit aussieht. Solange aber nicht mehrere Erlang-Nodes im Einsatz sind (heisst das so? Ist ne weile her), also letztlich explizites multi-processing + message-passing wie in Python mit dem multiprocessing-modul moeglich, ist Erlang schlicht nicht nebenlaeufig. Sondern konzeptionell tatsaechlich mit den Greenlets verwandt.
http://en.wikipedia.org/wiki/Erlang_(pr ... rientation
[edit] So, nachdem ich das nochmal selbst intensiver durchgelesen habe, ist das was ich schrieb schlicht Unfug. Erlang ist sehrwohl nebenlaeufig. Allerdings durch message-passing, womit es also auch als einzelner Node aehnlich einem multiprocessing-Ansatz ist. Aber ohne System-Prozess-Overhead. Verzeiht die Konfusion.
Du sprichst von Erlang als Gegenentwurf zu Python mit dem GIL fuer multi-threading, oder verstehe ich dich da falsch? Wenn ja, dann ist das so nicht richtig: erlang hat eine Programmier-Abstraktion, die nach echter Nebenlaeufigkeit aussieht. Solange aber nicht mehrere Erlang-Nodes im Einsatz sind (heisst das so? Ist ne weile her), also letztlich explizites multi-processing + message-passing wie in Python mit dem multiprocessing-modul moeglich, ist Erlang schlicht nicht nebenlaeufig. Sondern konzeptionell tatsaechlich mit den Greenlets verwandt.
http://en.wikipedia.org/wiki/Erlang_(pr ... rientation
[edit] So, nachdem ich das nochmal selbst intensiver durchgelesen habe, ist das was ich schrieb schlicht Unfug. Erlang ist sehrwohl nebenlaeufig. Allerdings durch message-passing, womit es also auch als einzelner Node aehnlich einem multiprocessing-Ansatz ist. Aber ohne System-Prozess-Overhead. Verzeiht die Konfusion.
Vielleicht nicht. Python 3 hat imo das Problem, dass es zu wenig Vorteile bietet um einen schnellen Umstieg zu bewirken. Ein Python 4 ohne GIL mit jit hätte vielleicht Chancen sich schneller durchzusetzen als Python 3.Hyperion hat geschrieben:Da selbst Python3 sich bis heute schwer tut, wäre ein solches Python, wie Du es vorschlägst, sicherlich mit noch weniger Akzeptanz gesegnet, oder?
Die durchwachsene Akzeptanz von Python 3 kann man durchaus als Chance sehen, man könnte es zu Gunsten einer radikaleren Veränderung begraben ohne dass das merklich weh tun würde.
-
BlackJack
@Darii: Vielleicht gibt's ja statt Python 4 doch noch eine Weiterentwicklung von 2.7 aus der PyPy-Ecke. JIT gibt es da ja schon. Ich perönlich finde PyPy jedenfalls interessanter als Python 3.
-
jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ja, PyPy ist wesentlich interessanter als Python 3. PyPy muß es allerdings noch schaffen, das Binär-Module ohne großen Probleme laufen. Das ist gerade das größte Problem, oder? Was nützt einem, das Django läuft, aber nur mit SQLite...
Ansonsten sind IMHO die Unterschiede von PyPy zu CPython v2 sehr viel geringer als Python v3 zu Python v2, aber unterm Strich bringt PyPy mehr...
Ansonsten sind IMHO die Unterschiede von PyPy zu CPython v2 sehr viel geringer als Python v3 zu Python v2, aber unterm Strich bringt PyPy mehr...
-
BlackJack
@jens: Ich denke nicht, dass es das erstrebenswerteste Ziel ist, dass PyPy möglichst gut die CPython-API emuliert, sondern dass die Modulanbieter anfangen Anbindungen zu schreiben, die `ctypes` verwenden. Davon hätte nicht nur PyPy etwas, sondern auch IronPython und Jython könnten sie dann verwenden. Sowie natürlich auch CPython. Dort hätte es den Vorteil, das nicht für jede CPython-Version alles neu kompiliert werden müsste. Was IMHO ein Punkt ist, weshalb Python aus Windows nicht so gut ankommt, wie es könnte. Windows-Benutzer — selbst Programmierer — kompilieren nicht so selbstverständlich eine C-Erweiterung wie das zum Beispiel unter Linux der Fall ist.
Aber da haben wir vielleicht das gleiche Problem wie bei CPython 3.x — wie motiviert man Drittanbieter ihre Module auf `ctypes` umzustellen…
Aber da haben wir vielleicht das gleiche Problem wie bei CPython 3.x — wie motiviert man Drittanbieter ihre Module auf `ctypes` umzustellen…
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? Hätte man vielleicht die als längst deprecated bezeichneten Funktionen zwar rausschmeißen, aber zumindest eine Kompatibilität zu bspw Python 2.5 wahren sollen? Das hätte zumindest dafür gesorgt, dass die allermeisten Drittpakete auch unter Python 3 noch nutzbar wären. Meines Erachtens ist nämlich der Fakt, dass dem leider nicht so ist, ein ganz wesentlich Minus. Ein wesentliches Plus an Python 3 ist IMHO wiederum der Einschnitt im String-Handling. Viel mehr bedeutende Vorteile als den letztgenannten sehe ich für mich eigentlich nicht.
Alte Zöpfe abschneiden ist ist schön und gut. Auch ein Neuanfang (Brechen mit alter API) kann manchmal sinnvoll sein. Aber eben nur dann, wenn es Neuerungen mit sich bringt, die einem echte Vorteile verschaffen. Davon hat Python 3 wie gesagt leider viel zu wenig. Und die Modulautoren haben bekanntlich nru wenig Lust auf entsprechende Anpassungen, wodurch die Portierung recht schleppend verläuft. Zudem muss man bedenken, dass manch ein Modul u.U. zwar noch seinen Dienst erfüllt, aber gar nicht mehr aktiv weiterentwickelt wird. Wenn man da nicht selbst Hand anlegt (was wiederum auch mit viel Arbeit verbunden sein kann), dann muss man leider die Konsequenzen ziehen und eben keinen Wechsel machen.
Alte Zöpfe abschneiden ist ist schön und gut. Auch ein Neuanfang (Brechen mit alter API) kann manchmal sinnvoll sein. Aber eben nur dann, wenn es Neuerungen mit sich bringt, die einem echte Vorteile verschaffen. Davon hat Python 3 wie gesagt leider viel zu wenig. Und die Modulautoren haben bekanntlich nru wenig Lust auf entsprechende Anpassungen, wodurch die Portierung recht schleppend verläuft. Zudem muss man bedenken, dass manch ein Modul u.U. zwar noch seinen Dienst erfüllt, aber gar nicht mehr aktiv weiterentwickelt wird. Wenn man da nicht selbst Hand anlegt (was wiederum auch mit viel Arbeit verbunden sein kann), dann muss man leider die Konsequenzen ziehen und eben keinen Wechsel machen.
Naja, Cython macht es ja vor. Besonders kompliziert und hässlich finde ich bei `ctypes` ja, dass man `struct`s, `typedef`s, `define`s, usw aufwändig nachbauen muss. Wenn `ctypes` das irgendwie selbst ermitteln könnte, dann wäre IMHO schon viel gewonnen. Zudem müsste man die API von `ctypes` mehr auf Plattformunabhängigkeit trimmen. Es existiert zwar ein `ctypes.util.find_library()`, aber das ist im Verhältnis zu seiner Wichtigkeit in meinen Augen relativ versteckt und wird auch viel zu wenig genutzt. Etwas wie `Library.from_name()` (als `classmethod`) käme da vielen sicher entgegen. Es wäre halt ziemlich praktisch, wenn die Mächtigkeit von `ctypes` zwar erhalten bliebe, aber die Einstiegshürde inbesondere beim Wrappen von Drittbibliotheken nicht so hoch wäre.BlackJack hat geschrieben:Aber da haben wir vielleicht das gleiche Problem wie bei CPython 3.x — wie motiviert man Drittanbieter ihre Module auf `ctypes` umzustellen…
-
deets
@snafu
Es gibt ja den gccxml. Und ich finde den Aufwand, Strukturen und calls zu wrappen wirklich ueberschaubar.
Es gibt ja den gccxml. Und ich finde den Aufwand, Strukturen und calls zu wrappen wirklich ueberschaubar.
-
BlackJack
@snafu: Ein (noch) fliessenderer Übergang wäre vielleicht besser gewesen. Also möglichst viel von 3.x nach 2.x portieren und in 2.x alles Inkompatible als `__future__`-Importe zur Verfügung stellen. Da ist ja auch viel in der Richtung passiert. Aber IMHO wäre es schön gewesen die 2.x-Reihe fort zu setzen und da die Änderungen aus der 3er-Reihe weiterhin auf diese Weise ein zu pflegen, so dass es irgendwann einen ganz „natürlicher” Übergang wird. So wie es jetzt ist, wird der Sprung von 2.7 zur jeweils aktuellen 3.x immer grösser.
IMHO sind auch Linux-Distributionen wichtig. Solange 3.x nicht gleichwertig in den Repositories der grossen Distributionen vertreten ist, steige ich nicht um. Sowohl Python selbst, als auch die wichtigsten Module/Pakete von Drittanbietern müssen einfach über die Paketverwaltung installierbar sein. Da ist die Frage ob die PSF sich hier engagieren sollte und Distributionen dabei Unterstützen sollte in Richtung Python 3 als Standardpython zu gehen.
IMHO sind auch Linux-Distributionen wichtig. Solange 3.x nicht gleichwertig in den Repositories der grossen Distributionen vertreten ist, steige ich nicht um. Sowohl Python selbst, als auch die wichtigsten Module/Pakete von Drittanbietern müssen einfach über die Paketverwaltung installierbar sein. Da ist die Frage ob die PSF sich hier engagieren sollte und Distributionen dabei Unterstützen sollte in Richtung Python 3 als Standardpython zu gehen.
-
jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Das sehe ich weniger als Problem. Mache eh alles mit virtuelenv und pip...BlackJack hat geschrieben:IMHO sind auch Linux-Distributionen wichtig. Solange 3.x nicht gleichwertig in den Repositories der grossen Distributionen vertreten ist, steige ich nicht um. Sowohl Python selbst, als auch die wichtigsten Module/Pakete von Drittanbietern müssen einfach über die Paketverwaltung installierbar sein. Da ist die Frage ob die PSF sich hier engagieren sollte und Distributionen dabei Unterstützen sollte in Richtung Python 3 als Standardpython zu gehen.
-
lunar
@snafu: ctypes kann Typen und Signaturen nicht selbst ermitteln, da diese in Bibliotheken (allgemein in kompiliertem Code) gar nicht mehr vorhanden sind.
@deets: Der Aufwand ist überschaubar, wenn die Bibliothek überschaubar ist. Ist die Bibliothek dagegen groß, oder hat eine überkomplexe Schnittstelle mit vielen Typedefs und Makros, so kann es durchaus ziemlich aufwendig und auch fehleranfällig sein, der Bibliothek Informationen über Typen und Signaturen abzuringen. MAn versuche nur mal, aus den X11-Headern Informationen über die Größe der Basistypen abzugewinnen, oder die oftmals geschachtelten Union- und Strukturdefinitionen nachzuvollziehen.
@BlackJack: ctypes funktioniert halt nur mit C, und auch nur innerhalb gewisser technischer Grenzen. Man kann keine Funktionen mit variablen Argumenten wrappen, bzw. schreiben (um sie als Callbacks an C-Funktionen zu übergeben) und kann logischerweise keine Inline-Funktionen und Makros aufrufen. Und es fehlt eben C++-Unterstützung. Sicher, C++ möchte man eigentlich nicht nutzen, aber man muss es eben ab und zu, denn die eine oder andere nicht ganz unwichtige Bibliothek ist halt doch in C++ geschrieben.
@jens: Du als Entwickler, doch die Nutzer Deiner Anwendungen sind an den Distributionsstandard gebunden. Somit sind das auch alle Entwickler, deren Zielgruppe von virtualenv, pip und Konsorten noch nie etwas gehört hat.
@deets: Der Aufwand ist überschaubar, wenn die Bibliothek überschaubar ist. Ist die Bibliothek dagegen groß, oder hat eine überkomplexe Schnittstelle mit vielen Typedefs und Makros, so kann es durchaus ziemlich aufwendig und auch fehleranfällig sein, der Bibliothek Informationen über Typen und Signaturen abzuringen. MAn versuche nur mal, aus den X11-Headern Informationen über die Größe der Basistypen abzugewinnen, oder die oftmals geschachtelten Union- und Strukturdefinitionen nachzuvollziehen.
@BlackJack: ctypes funktioniert halt nur mit C, und auch nur innerhalb gewisser technischer Grenzen. Man kann keine Funktionen mit variablen Argumenten wrappen, bzw. schreiben (um sie als Callbacks an C-Funktionen zu übergeben) und kann logischerweise keine Inline-Funktionen und Makros aufrufen. Und es fehlt eben C++-Unterstützung. Sicher, C++ möchte man eigentlich nicht nutzen, aber man muss es eben ab und zu, denn die eine oder andere nicht ganz unwichtige Bibliothek ist halt doch in C++ geschrieben.
@jens: Du als Entwickler, doch die Nutzer Deiner Anwendungen sind an den Distributionsstandard gebunden. Somit sind das auch alle Entwickler, deren Zielgruppe von virtualenv, pip und Konsorten noch nie etwas gehört hat.
@lunar: Stimmt natürlich. Ich hatte nicht bedacht, dass das Konzept von `ctypes` ja auf kompilierten Bibliotheken beruht, während das von mir als Vergleich herangezogene Cython natürlich auf dem Quelltext arbeitet und somit im Gegensatz zu `ctypes` auf Vorhandensein der jeweiligen "Entwicklerversion" einer Bibliothek auf dem System den Benutzers angewiesen ist.
-
deets
@lunar
Klar gibt es da Komplexitaetsunterschiede. Ich habe mir aber zB bei irgendwelchen ioctl-calls in Linux fuer arkane Devices da immer schnell die typedefs und Makros nachgebaut. Damit liessen sich dann die notwendigen Deklarationen leicht nachbauen. Und zB hat der gccxml gerade mal im Test auch problemlos die X.h geschluckt. Habe aber zuzugebendermassen damit lange nix mehr gemacht.
Oft genug reicht man ja eh nur Pointer durch die Gegend, die fuer den Python-Code auch opaque sein koennen - da deklariere ich eine Struktur erst gar nicht bis zu Ende.
Es ist IMHO immer noch deutlich angenehmer, als die Alternativen - handgekloeppelte Extensions, aber auch Cython finde ich fuer C nicht wirklich gut. Alleine schon, weil ein Compiler gebraucht wird.
Klar gibt es da Komplexitaetsunterschiede. Ich habe mir aber zB bei irgendwelchen ioctl-calls in Linux fuer arkane Devices da immer schnell die typedefs und Makros nachgebaut. Damit liessen sich dann die notwendigen Deklarationen leicht nachbauen. Und zB hat der gccxml gerade mal im Test auch problemlos die X.h geschluckt. Habe aber zuzugebendermassen damit lange nix mehr gemacht.
Oft genug reicht man ja eh nur Pointer durch die Gegend, die fuer den Python-Code auch opaque sein koennen - da deklariere ich eine Struktur erst gar nicht bis zu Ende.
Es ist IMHO immer noch deutlich angenehmer, als die Alternativen - handgekloeppelte Extensions, aber auch Cython finde ich fuer C nicht wirklich gut. Alleine schon, weil ein Compiler gebraucht wird.
in diesem Zusammenhang vllt. ganz interessant: http://morepypy.blogspot.com/2011/08/we ... emory.html
-
lunar
@deets: Die XML-Ausgabe von gccxml muss man aber auch erst mal in Python-Quelltext verwandeln, und Makros gibt es in der gccxml-Ausgabe gar nicht mehr.
Ich sage ja im Übrigen auch nicht, dass ctypes schlecht ist, im Gegenteil, ich nutze es sehr gerne. Nur ist es eben kein vollständiger Ersatz für cython, oder für die C-API im Allgemeinen.
Ich sage ja im Übrigen auch nicht, dass ctypes schlecht ist, im Gegenteil, ich nutze es sehr gerne. Nur ist es eben kein vollständiger Ersatz für cython, oder für die C-API im Allgemeinen.
Ich persönlich würde Python nicht daran messen wollen, wie gut (Legacy-)C-Bibliotheken eingebunden werden können. Ich weiß, dass das für viele hier wichtig ist, aber eine Sprache muss IMHO für sich selbst einstehen können und praktikabel sein, ohne dass man selbst andere Bibliotheken einbinden muss.
Betrachten wir das C-API im folgenden nicht weiter, möchte ich behaupten, dass Python 3 nicht mit mehr Kompatibilität zu Python 2.x besser akzeptiert worden wäre sondern im Gegenteil mit weniger Kompatibilität. Oder anders ausgedrückt: Python 3 hätte mir mehr bieten müssen, als nur ein ganz kleines bisschen besser zu sein. Das man `print` oder `exec` zu Funktionen gemacht hat, hat keine große Wirkung. Eine klare (und korrekte) Trennung von Strings und Byte-Arrays war überfällig, wird aber von der Mehrzahl der Entwickler nicht verstanden und als lästig empfunden. Zudem hatte man für WSGI das ganze vermurkst.
Die großen Features, die jeder haben wollte, gab es aber nicht.
Was hätten das für Features sein können?
Vielleicht Nebenläufigkeit inklusive einer Actor-Syntax. Allgemein wäre Pattern-Matching als Syntax-Erweiterung eine nette Idee. Oder wie wäre es damit gewesen, wenn man ein einheitliches modernes UI standardisiert und Tk abgelöst hätte. 1996 gab es mit HyperCard die Killeranwendung schlecht hin, VisualBasic von 1991 oder so und brachte eine Revolution, was GUI-Programmierung anging. Warum wurde das alles wieder vergessen. Heutzutage wäre es IMHO besser, auf Webkit als Basis aufzusetzen, doch das ist ein anderes Thema. Interessant für einige Anwendungsfälle wäre ein Zugriff auf den Sprach-AST. Auch ein Projekt, die Sprache derart zu ändern, damit man z.B. die doppelte Geschwindigkeit erreichen könnte, wäre interessant gewesen.
Welche Ideen habt ihr noch?
Jetzt aber wurde bei Python 3 nur repariert, was viele gar nicht als kaputt (genug) angesehen hatten und kaputt gemacht, was vielen (Unix-)Nutzern an's Herz gewachsen ist und daher haben wir immer noch Python 2.7.
Stefan
Betrachten wir das C-API im folgenden nicht weiter, möchte ich behaupten, dass Python 3 nicht mit mehr Kompatibilität zu Python 2.x besser akzeptiert worden wäre sondern im Gegenteil mit weniger Kompatibilität. Oder anders ausgedrückt: Python 3 hätte mir mehr bieten müssen, als nur ein ganz kleines bisschen besser zu sein. Das man `print` oder `exec` zu Funktionen gemacht hat, hat keine große Wirkung. Eine klare (und korrekte) Trennung von Strings und Byte-Arrays war überfällig, wird aber von der Mehrzahl der Entwickler nicht verstanden und als lästig empfunden. Zudem hatte man für WSGI das ganze vermurkst.
Die großen Features, die jeder haben wollte, gab es aber nicht.
Was hätten das für Features sein können?
Vielleicht Nebenläufigkeit inklusive einer Actor-Syntax. Allgemein wäre Pattern-Matching als Syntax-Erweiterung eine nette Idee. Oder wie wäre es damit gewesen, wenn man ein einheitliches modernes UI standardisiert und Tk abgelöst hätte. 1996 gab es mit HyperCard die Killeranwendung schlecht hin, VisualBasic von 1991 oder so und brachte eine Revolution, was GUI-Programmierung anging. Warum wurde das alles wieder vergessen. Heutzutage wäre es IMHO besser, auf Webkit als Basis aufzusetzen, doch das ist ein anderes Thema. Interessant für einige Anwendungsfälle wäre ein Zugriff auf den Sprach-AST. Auch ein Projekt, die Sprache derart zu ändern, damit man z.B. die doppelte Geschwindigkeit erreichen könnte, wäre interessant gewesen.
Welche Ideen habt ihr noch?
Jetzt aber wurde bei Python 3 nur repariert, was viele gar nicht als kaputt (genug) angesehen hatten und kaputt gemacht, was vielen (Unix-)Nutzern an's Herz gewachsen ist und daher haben wir immer noch Python 2.7.
Stefan
Und noch mal etwas mehr OT, FYI, falls nicht schon erwähnt: http://morepypy.blogspot.com/2011/08/we ... emory.html
Stefan
Stefan