Von DerBeobachter am Do, 22. Oktober 2009 um 13:41 #
Also natürlich ist es nicht leicht Projekte zu "portieren" bzw. auf neuere Versionen umzustellen. Aber bei Python (3.x bzw 2.6) wirds einem schon sehr einfach gemacht. Warum das so ein großes Problem sein sollte verstehe ich gerade nicht.
Nein, das groesste Problem ist in den Standardbibliotheken. Diese haben teilweise erhebliche Fehler. Beispielsweise konnten viele HTTP-Requests ueber urllib nicht mehr korrekt gesendet werden, da Chunked Antworten inkorrekt interpretiert wurden. Dies wuerde erst jetzt mit Python 3.1 korrigiert. Wenn nun jemand eine Bibliothek/Programm hat, dass die Funktionalitaet benutzt, wird er sehr schnell aufhoeren diese zu portieren, wenn er an solche Probleme stoest. Ich kenne relativ viele Leute, die genau aus diesem Grund gerade einmal die Warnungen aus Python 2.6 korrigieren, aber nicht mehr interessiert sind es in naechster Zeit auf 3.x zu portieren.
gemeint sind auch eher Projekte wie numpy, die haben einen erheblichen Aufwand für die Portierung ... und ohne numpy/scipy können wir auch nicht migrieren ...
Ganz so einfach ist es nicht. Bei größeren Projekten kann es schon einiges an Aufwand bedeuten die Portierung durchzuführen. Längerfristig muss man das sicherlich angehen, aber kurzfristig bringt die Portierung einfach noch keine Vorteile.
Bei neuen Projekten sieht das anders aus, aber ich werde mit der Portierung bestehender Projekte abwarten.
Von Juergen Hamel am Do, 22. Oktober 2009 um 15:13 #
Nun, das ist vielleicht ganz einfach zu sehen. Mein Projekt (CUON) hat ca. 200 Quelldateien und importiert grob geschätzt 40 unterschiedliche, nicht zu Python gehörige Module. Ich kann also mein Projekt erst dann updaten, wenn die Module alle auf 3.1 laufen und , ebenso wichtig, auch auf Windows portiert sind.Das wird vielleicht noch Jahre dauern.
Und diese Arbeit muß ich mir machen, weil der print Befehl geändert wurde ? Tut mir leid, ich bin nicht begeistert davon. Ich weiß, das Rückwärtskompatibilität nicht jedermanns Wunsch ist, aber hier wäre es durchaus angebracht gewesen. Und was wäre denn verloren gegangen, wenn der Interpreter print ".." und print(" ") verstanden hätte ?
Wenn es eine Abwärtskompatibilität gegeben hätte, wären wir jetzt mit Python schon viel weiter !
Naja, Rückwärtskompatibilität passt wohl nicht ganz zu "There should be one-- and preferably only one --obvious way to do it.".
Jetzt ist die Frage: soll man es sich grundlegende "Regeln" - welche dazu beigetragen haben die Sprache populär zu machen - brechen, um einige Unannehmlichkeiten zu vermeiden? Ich finde es durchaus in Ordnung nicht immer kompatibel zu sein. Gerade im Fall von Python sehe ich hier nicht wirklich die großen Probleme. Es ist absolut problemlos möglich zwei oder mehrere Versionen von Python auf einem System zu haben, welche sich gegenseitig nicht beeinträchtigen. Für Projekte welche nicht portieren kann/will, besteht absolut keine Gefahr und kein Druck. Man kann sie einfach erstmals auf Python 2.6 weiter laufen lassen.
Von Juergen Hamel am Do, 22. Oktober 2009 um 21:39 #
>Es ist absolut problemlos möglich zwei oder mehrere Versionen von >Python auf einem System zu haben, welche sich gegenseitig nicht >beeinträchtigen. Für Projekte welche nicht portieren kann/will, >besteht absolut keine Gefahr und kein Druck. Man kann sie einfach >erstmals auf Python 2.6 weiter laufen lassen. Ich sehe da durchaus Probleme, viele Python-Programme rufen einfach als start "python" auf, und bei weitem nicht alle Anwender wissen das zu ändern, wenn python auf python3xx zeigt, aber es ein python2.6xxx Programm ist. Einfach den Symlink zu ändern geht auch nicht, da dann python 3.xx Programme nicht mehr laufen. Und der Druck ist durchaus da, da eben die Projekte nicht migrieren. Meiner Meinung nach sieht es so aus, das dies ein Problem der nächsten Jahre wird. Ich mag Python sehr und programmiere seit 8 jahren in Python, trotzdem war diese fehlende Abwärtskompatibilität meiner Meinung nach das hirnrissigste, das ich mir in der Python Welt vorstellen kann. Das alles wächst sich zu einem Gau aus, denn für mich gibt es durchaus erschreckende Szenarien: Bibliothek X1 migriert zu Python3 und wird darin weiterentwickelt und behebt kritische Sicherheitslücken, aber Bibliothek Y2 will nicht migrieren. Also kann mein Programm, das X1 und Y2 benötigt, nur noch mit der alten Bibliothek X1 und den Sicherheitslücken laufen. Keine schöne Vorstellung.
Das ist auch einer der Gründe, warum man den Interpreter immer explizit aufruft und das nicht der Auswertung der Interpreteranweisung im Skript überlässt.
Was Deine Aussage bezüglich der Rückwärtskompatibilität anbetrifft, so frage ich mich trotzdem, wieso 2.6 nicht vollkommen ausreichend ist, auch für die Jahre, die eine fertige Modulportierung auf 3.x noch brauchen sollte. 2.6 ist ja nicht nur rückwärts-, sondern auch in großen Teilen vorwärtskompatibel. Insofern kann man viele nette Sprachfeatures bereits jetzt mit 2.6 ausgiebig nutzen.
die im Sinn besagt: Wenn es schon etwas gibt, dann nutze dies.
Und so haben es die meisten gemacht. Während in anderen Sprachen (zb. PHP) jeder gerne alles noch mal selber macht, wird bei python zuerst geschaut ob es ein fertiges Modul für die Teilaufgabe gibt. Entsprechend wartet jetzt jeder mit seinem Projekt darauf, dass die Module in der 3er verfügbar sind, einzelne Modulentwickler warten auf andere Modulentwickler. In der Hoffnung, keiner in der Kette ist verschollen.
Oder man muss doch anfangen die Funkttionen selbst für sein Programm zu programmieren.
> Wenn es schon etwas gibt, dann nutze dies. Das hat doch mit dem Thema nichts zu tun. Es wurde kein neues Element und auch keine neue API "erfunden", sondern lediglich ein Sprachkonstrukt in einen Funktionsaufruf überführt. Das ist nur konsequent und funktioniert in dieser Form bereits mit der 2.x-Linie. Insofern könnte auch dieser Umstieg weicher nicht sein.
> Und was wäre denn verloren gegangen, wenn der Interpreter print ".." und print(" ") verstanden hätte ? Es hängt doch gar nicht am print(), woher kommt das immer? print -> print() wird bereits vom automatischen Transformationstool (2to3) abgefrühstückt, da muss der Portierer in den allermeisten Fällen nicht eine Sekunde lang Hand anlegen.
Von Juergen Hamel am Fr, 23. Oktober 2009 um 12:14 #
>Es hängt doch gar nicht am print(), woher kommt das immer? print -> print() wird bereits vom >automatischen Transformationstool (2to3) abgefrühstückt, da muss der Portierer in den allermeisten Fällen >nicht eine Sekunde lang Hand anlegen. A) sind nicht alle Änderungen so einfach, und die Problematik ist natürlich nicht, das ich mein Program upgrade, sondern das die "Imports" nicht in der neuen Version zur Verfügung stehen. B) ist nicht alles so einfach wie es aussieht, ich habe z.B. plötzlich Speicherzugriffsfehler in meinen Programm, habe lange gesucht, es hängt anscheined mit der libglade zusammen, bei bestimmten Glade Dateien kam es eben zu diesen Fehler. Viele Stunden später und dank dieses Artikels bin ich dann auf die Idee gekommen, das es der parameter -3 in python 2.6 war, der mir helfen sollte, die Kompatibilität zu prüfen. c) Ich versuche schon seit fast einem Jahr, Möglichkeiten zum Upgrade zu finden, kann aber nicht mal anfangen, weil zwar 2.6 ein paar 3`er Konstrukte versteht, nicht aber 2.4! Und eben dieses 2.4 wird noch in vielen Windows XP clients angewendet. Um überhaupt weiterzukommen werde ich den unschönen weg über try.. except gehen, evtl. komme ich damit weiter, also try ..3.x version des Befehls except .. 2.4 version des Befehls.
im Gegenteil, es ist super logisch. Von einer Methode erwartest Du, dass sie als Parameter das Objekt bekommt. Das soll sie dann bei Dir aber freigeben, obwohl sie selbst eine Referenz darauf hält?
In allen Sprachen, die mir so einfallen, ist es deshalb keine Methode.
Aber nur so am Range, wenn Du del aufrufst, machst Du (in Python) schon was falsch. Das kann der Interpreter doch sehr gut selbst.
Mit del gibst du ein Objekt nicht frei. Du entfernst einen Bezeichner aus dem Local-Scope. Wenn dadurch der RefCount eines Objektes auf 0 heruntergesetzt wird, dann wird es auch freigegeben. Aber das muss nicht der Fall sein:
>>> class A: ... def __del__(self): ... print("delete " + str(self)) ... >>> a = A() >>> x = a >>> del a >>> del x delete <__main__.A object at 0x7fe7d9a478d0> >>>
Erst wenn beide Bezeichner gelöscht sind, wird das Objekt freigegeben.
Das Problem von Python ist genau dieses. Ich habe einmal versucht mit einer Ubuntu-Version versucht, ein System mit einer aktuellen Turbo-Gears Version zusammenzubauen. Es endete damit, dass ich mit einer Art virtuellen Python-Umgebung arbeiten musste. So geht das nicht gut.
Ich weiß nicht ob das der Vorredner meint, aber der symbol. Link "python" hat als Ziel die 2.6er Version - war zum. bei mir so. Es gibt sehr lustige Fehler, wenn man dieser Symlink auf die 3 Version richtet.
> Aber beide zusammen laufen nicht. Ich habe drei Python-Versionen installiert (2.5, 2.6, 3.1). Eine ist die default-Version meines Distributors, die beiden anderen habe ich von python.org und selbst gebaut. Und es funktioniert wie erwartet. Wenn es das bei dir nicht tut, solltest du dich an die Macher deines Systems wenden.
> die beiden anderen habe ich von python.org und selbst gebaut
Und genau das kann man nicht von jedem Nutzer (nicht Entwickler!) erwarten. Python wird schließlich auch für GUI-Anwendungen verwendet, die sich auch an DAUs richten.
> Und genau das kann man nicht von jedem Nutzer (nicht Entwickler!) erwarten.
Aber von den Entwicklern Ubuntus, oder? Die müssen nämlich genau garnichts machen außer upstream mit dem Dreisatz abfrühstücken, allenfalls einen Symlink auf die gewünschte default-Version setzen. Oder, der OP hat sich schlicht verfahren. Kann passieren.
> Die müssen nämlich genau garnichts machen außer upstream mit dem Dreisatz abfrühstücken
Die müssen den Kram auch dann noch bei Sicherheitslücken patchen, wenn sich Upstream dafür nicht mehr interessiert. Und das für python2.3, python2.4, python2.5, python2.6, python3.0 und python3.1, Tendenz steigend. Andere Sprachen haben solche Probleme nicht.
Doch, durchaus. Ich kenne eigentlich keine Interpreter-Sprache die nicht das Problem haben das es scripte gibt die nicht auf allen Versionen laufen. Python ist nur mutiger gewesen, und entwickelt sich trotzt des alters noch dynamischer als manch eine andere Sprache.
Typische Beispiele für solche Probleme sind PHP, wo auch Minorversionen probleme erzeugen, und natürlich Perl, das verschiebt das Problem aktuell nur Jahr um Jahr.
Von realistisch Denkender am Di, 27. Oktober 2009 um 10:06 #
Praktisch alle Sprachen haben dieses Problem. Ist bei Perl, C#, Ruby und Lua doch auch nicht anders. Andere Sprachen wie Java, C, C++ und D haben nur das "Glück", dass deren Entwickler oder/und die Entwickler der Compiler ihrem Terminplan nicht hinterherkommen. (Warum auch immer) Da werden dann aus zwei Jahren Entwicklungszeit glatt mal 8-10 Jahre. Gut für die Programmierer, wenn es sich nur im Schönheitsoperationen handelt.
Das verstehe ich nicht. Du kannst problemlos parallel python2.6 und python3 installieren, und auch beide nutzen.
Wo sollte das Problem sein? Ubuntu liefert für beides Pakete mit, die du gleichzeitig installieren und nutzen kannst. Ich sehe da keine Probleme. Ich selbst nutze Anwendungen die auf 2.x aufbauen, und welche die auf python3 aufbauen. Zur selben Zeit.
> Die die du brauchst? War jetzt nicht soo schwer.
Wenn ich (mind.) Python 2.4 brauche, auf einem Zielsystem aber Python 2.5 installiert ist, läuft das Programm nicht, weil dort kein python-2.4 existiert. Und nicht jeder will jede Minor-Version von Python installieren, zumal manche Distributionen sie auch gar nicht anbieten und es auch gar nicht notwendig ist, wenn das Programm auch mit Python 2.5 laufen würde. Konsequenz wäre wohl, jedes Programm als Download für jede Python-Version anzubieten mit dem einzigen Unterschied, dass die Versionsangabe im Shebang ne andere ist.
Worauf willst du hinaus? Wer runtime_env_foobar braucht, sucht sich ein Sytem das diese anbietet, oder er muß sich selbst kümmern. Ob man das mag oder nicht hilft bei der Lösung Stück. Im vorliegenden Fall hapert es beim OP mit dem parralelen Betrieb von Python-2.6.x und Python-3.x. Das geht auf die Kappe des OP oder der Ubuntu-Entwickler.
Von Juergen Hamel am Fr, 23. Oktober 2009 um 20:35 #
> !#/usr/bin/env python-$Version
des OP, der Ubuntu-Entwickler, RED-Hat, SuSE, Debian, .... und als letztes Microfsoft. Sorry, aber du kannst nicht jeder Firma und jedem Dau zumuten, das auf seinem System 18 Python-Versionen installiert sind, jeweils mit den entsprechenden 140 benötigten Zusatzbibliotheken. DAS ist meiner Meinung nach weltfremd! Und deshalb ist dieser Umstieg auf Python3 gescheitert!
Deinen Beitrag weiter oben hab ich gelesen, ebenso die Tabelle mit Informationen über die Projektgröße von CUON; und ich kann deine Kopfschmerzen nachvollziehen. Nur hilft die Einstellung zu Kompatibilitätsbrüchen, positiv oder negativ, dem Poster der hier und jetzt zwei Python-Versionen in einer expliziten Umgebung betreiben will nicht. Das ist ein völlig anderes Thema. Wenn du in meine Sätze also hineininterpretierst ich argumentiere pro Komp.-Brüche, liegst du falsch.
Von Juergen Hamel am Fr, 23. Oktober 2009 um 23:59 #
Hallo, bitte verstehe es richtig, ich wollte nur die Problematik aufzeigen, weil weiter oben von Faulheit, mehreren Interpreter-Installationen und ähnlichen die Rede war. Mit meinen Beitrag wollte ich nur aufzeigen, das es evtl. einen besseren Weg gegeben hätte. Eben weil Python so wichtig ist und so viele Projekte existieren, ist eine Rückwärtskompatibilität so wichtig. Es wäre m.M. nach dann wesentlich schneller vorangegangen.
> Worauf willst du hinaus? Wer runtime_env_foobar braucht, sucht sich ein Sytem das diese anbietet, oder er muß sich selbst kümmern. Ob man das mag oder nicht hilft bei der Lösung Stück.
Es gibt Python-Anwendungen, die mit Python ab 2.4 funktionieren. Sie laufen auch mit 2.5 und 2.6. Wenn man jetzt python-2.4 im Shebang einträgt, zwingt man den Nutzer dazu, Python 2.4 zu installieren oder gar die Distribution zu wechseln, obwohl Python 2.5 es auch getan hätte.
Programmiersprachen sind etwas langlebiges - zumindest die "erfolgreichen". Ein Wechsel wird in so einem Sektor immer wesentlich länger dauern, als bei Programmen oder auch Desktop-Umgebungen. Selbst KDE3 wird noch sicherlich auch 2 Jahre nach KDE4 noch weiter ausgeliefert von Distributionen. Ich vermute erst in 1,5 Jahren wird es dann endgültig "tot" sein.
Eine Programmiersprache ist da noch diffizieler. Aber das ist imho kein Problem. Wer zig Programme unter 2.x laufen hat, der soll diese doch ruhig noch weitere Jahre pflegen. Dann kann er ggf. paralle eine Portierung vornehmen, oder gar eine komplette Neuentwicklung.
Problematisch wird es doch nur für die Neuentwicklungen, die etwas benötigen, das es noch nicht portiert gibt! Allerdings lässt sich dieses Henne-Ei-Problem auch nicht mit der Brechstange lösen. Peux a peux werden viele Libs portiert oder es entstehen Neuentwicklungen, die diese Lücken füllen. So wird man früher oder später alle Bedürfnisse für 3.x erfüllen und immer mehr Entwickler werden umsteigen.
So lange sollte man eben die 2.xer Serie weiterpflegen und auf eine längere SIcht parallel als gleichwertig ansehen. Genau das passiert ja aber auch.
Und Guido hat sicherlich recht, wenn er nun die Stabilität und Perfektionierung anmahnt. Das gibt auch anderen Projekten wie Jython, PyPy usw. die Chance, die 3er Reihe von CPython einzuholen und näher an diesem Zweig dran zu sein.
Sehr Lobenswert auch mal eine Pause einzulegen und sich wirklich erstmal darum zu kümmern was man schon hat, den Entwicklern auch zu verkaufen. Python3 ist im Grunde genommen tot oder besser gesagt nie wirklich geboren, im Sinne das es auch von jemanden benutzt wird. Das war ein ziemlicher Fehlgriff insbesondere weil man so ein Sprachänderung erst freigeben sollte, wenn wirklich alle Module auch angepasst sind und es auch für einen Entwickler Sinn macht sich über eine Portierung Gedanken zu machen.
Das war ein ziemlicher Fehlgriff insbesondere weil man so ein Sprachänderung erst freigeben sollte, wenn wirklich alle Module auch angepasst sind und es auch für einen Entwickler Sinn macht sich über eine Portierung Gedanken zu machen.
Nein, das macht überhaupt keinen Sinn! Die Core-Module sicher, aber die Standard-Lib war ja vollständig. Aber 3rd Party Module können ja erst dann auf Python 3 migrieren, sobald es eine finale Version gibt. Oder würdest Du deine App anpassen, wenn die Lib nicht stabil ist? Zudem bewirkt ein Release natürlich auch Aufmerksamkeit. Nein, nein, das war schon ein richtiger Schritt. Dass manche Dinge wie WSGI-Spec noch nicht auf Python 3 zugeschnitten sind, ist natürlich unglücklich. Aber so etwas passiert eben bei großen Projekten.
Wenn man ernstgenommen werden will, kann man nicht ständig etwas ändern und die Arbeit anderer damit zunichte machen.Damit sägt man sich nur selbst den Ast ab, auf dem man sitzt.
Möge diese Botschaft auch bei Projekten wie KDE oder Qt ankommen.
Möge diese Botschaft auch bei Projekten wie KDE oder Qt ankommen.
Ähem... Speziell bei KDE gibt es zig Parallelen zu Python! Sicherlich spielst Du auf KDE 4 an; genau dieser Wechsel ist ja mit dem Schritt von Python 2 auf 3 super zu vergleichen. Bei Qt war der Sprung von 3 auf 4 sicherlich ebenfalls groß, aber eben auch berechtigt.
In Python 3 sind nun einmal viele Dinge gerade gerückt worden, die im 2er Ast gestört haben und nun endlich aufgrund der Nicht-Rückwärtskompatibilität erledigt werden konnten. Bei jedem großen Projekt stößt man nun einmal an Grenzen. Da ist ein harter Wechsel oftmals notwendig. Wo genau siehst Du nun also den markanten Unterschied zu KDE und Qt?
Aber bei Python (3.x bzw 2.6) wirds einem schon sehr einfach gemacht. Warum das so ein großes Problem sein sollte verstehe ich gerade nicht.
Bei neuen Projekten sieht das anders aus, aber ich werde mit der Portierung bestehender Projekte abwarten.
Und diese Arbeit muß ich mir machen, weil der print Befehl geändert wurde ? Tut mir leid, ich bin nicht begeistert davon.
Ich weiß, das Rückwärtskompatibilität nicht jedermanns Wunsch ist, aber hier wäre es durchaus angebracht gewesen. Und was wäre denn verloren gegangen, wenn der Interpreter print ".." und print(" ") verstanden hätte ?
Wenn es eine Abwärtskompatibilität gegeben hätte, wären wir jetzt mit Python schon viel weiter !
Tschüss
Jürgen
Jetzt ist die Frage: soll man es sich grundlegende "Regeln" - welche dazu beigetragen haben die Sprache populär zu machen - brechen, um einige Unannehmlichkeiten zu vermeiden? Ich finde es durchaus in Ordnung nicht immer kompatibel zu sein.
Gerade im Fall von Python sehe ich hier nicht wirklich die großen Probleme. Es ist absolut problemlos möglich zwei oder mehrere Versionen von Python auf einem System zu haben, welche sich gegenseitig nicht beeinträchtigen. Für Projekte welche nicht portieren kann/will, besteht absolut keine Gefahr und kein Druck. Man kann sie einfach erstmals auf Python 2.6 weiter laufen lassen.
>Python auf einem System zu haben, welche sich gegenseitig nicht
>beeinträchtigen. Für Projekte welche nicht portieren kann/will,
>besteht absolut keine Gefahr und kein Druck. Man kann sie einfach
>erstmals auf Python 2.6 weiter laufen lassen.
Ich sehe da durchaus Probleme, viele Python-Programme rufen einfach als start "python" auf, und bei weitem nicht alle Anwender wissen das zu ändern, wenn python auf python3xx zeigt, aber es ein python2.6xxx Programm ist. Einfach den Symlink zu ändern geht auch nicht, da dann python 3.xx Programme nicht mehr laufen.
Und der Druck ist durchaus da, da eben die Projekte nicht migrieren. Meiner Meinung nach sieht es so aus, das dies ein Problem der nächsten Jahre wird.
Ich mag Python sehr und programmiere seit 8 jahren in Python, trotzdem war diese fehlende Abwärtskompatibilität meiner Meinung nach das hirnrissigste, das ich mir in der Python Welt vorstellen kann.
Das alles wächst sich zu einem Gau aus, denn für mich gibt es durchaus erschreckende Szenarien: Bibliothek X1 migriert zu Python3 und wird darin weiterentwickelt und behebt kritische Sicherheitslücken, aber Bibliothek Y2 will nicht migrieren. Also kann mein Programm, das X1 und Y2 benötigt, nur noch mit der alten Bibliothek X1 und den Sicherheitslücken laufen. Keine schöne Vorstellung.
Tschüss
Jürgen
Was Deine Aussage bezüglich der Rückwärtskompatibilität anbetrifft, so frage ich mich trotzdem, wieso 2.6 nicht vollkommen ausreichend ist, auch für die Jahre, die eine fertige Modulportierung auf 3.x noch brauchen sollte. 2.6 ist ja nicht nur rückwärts-, sondern auch in großen Teilen vorwärtskompatibel. Insofern kann man viele nette Sprachfeatures bereits jetzt mit 2.6 ausgiebig nutzen.
lg
Erik
Na wenn das dein einziges Problem ist...
die im Sinn besagt: Wenn es schon etwas gibt, dann nutze dies.
Und so haben es die meisten gemacht. Während in anderen Sprachen (zb. PHP) jeder gerne alles noch mal selber macht, wird bei python zuerst geschaut ob es ein fertiges Modul für die Teilaufgabe gibt. Entsprechend wartet jetzt jeder mit seinem Projekt darauf, dass die Module in der 3er verfügbar sind, einzelne Modulentwickler warten auf andere Modulentwickler. In der Hoffnung, keiner in der Kette ist verschollen.
Oder man muss doch anfangen die Funkttionen selbst für sein Programm zu programmieren.
Das hat doch mit dem Thema nichts zu tun. Es wurde kein neues Element und auch keine neue API "erfunden", sondern lediglich ein Sprachkonstrukt in einen Funktionsaufruf überführt. Das ist nur konsequent und funktioniert in dieser Form bereits mit der 2.x-Linie. Insofern könnte auch dieser Umstieg weicher nicht sein.
lg
Erik
Es hängt doch gar nicht am print(), woher kommt das immer? print -> print() wird bereits vom automatischen Transformationstool (2to3) abgefrühstückt, da muss der Portierer in den allermeisten Fällen nicht eine Sekunde lang Hand anlegen.
lg
Erik
>automatischen Transformationstool (2to3) abgefrühstückt, da muss der Portierer in den allermeisten Fällen
>nicht eine Sekunde lang Hand anlegen.
A) sind nicht alle Änderungen so einfach, und die Problematik ist natürlich nicht, das ich mein Program upgrade, sondern das die "Imports" nicht in der neuen Version zur Verfügung stehen.
B) ist nicht alles so einfach wie es aussieht, ich habe z.B. plötzlich Speicherzugriffsfehler in meinen Programm, habe lange gesucht, es hängt anscheined mit der libglade zusammen, bei bestimmten Glade Dateien kam es eben zu diesen Fehler. Viele Stunden später und dank dieses Artikels bin ich dann auf die Idee gekommen, das es der parameter -3 in python 2.6 war, der mir helfen sollte, die Kompatibilität zu prüfen.
c) Ich versuche schon seit fast einem Jahr, Möglichkeiten zum Upgrade zu finden, kann aber nicht mal anfangen, weil zwar 2.6 ein paar 3`er Konstrukte versteht, nicht aber 2.4! Und eben dieses 2.4 wird noch in vielen Windows XP clients angewendet.
Um überhaupt weiterzukommen werde ich den unschönen weg über try.. except gehen, evtl. komme ich damit weiter, also try ..3.x version des Befehls except .. 2.4 version des Befehls.
Tschüss
Jürgen
Von dem zu löschenden Obekt?
Oder doch eher eine Methode der Python-Maschine?
im Gegenteil, es ist super logisch. Von einer Methode erwartest Du, dass sie als Parameter das Objekt bekommt. Das soll sie dann bei Dir aber freigeben, obwohl sie selbst eine Referenz darauf hält?
In allen Sprachen, die mir so einfallen, ist es deshalb keine Methode.
Aber nur so am Range, wenn Du del aufrufst, machst Du (in Python) schon was falsch. Das kann der Interpreter doch sehr gut selbst.
Gruss,
Kay
>>> class A:
... def __del__(self):
... print("delete " + str(self))
...
>>> a = A()
>>> x = a
>>> del a
>>> del x
delete <__main__.A object at 0x7fe7d9a478d0>
>>>
Erst wenn beide Bezeichner gelöscht sind, wird das Objekt freigegeben.
> dass sie als Parameter das Objekt bekommt.
Nein, ist es nicht. Nein, erwarte ich nicht.
Von einer Methode erwarte ich das sie selbst weiß zu welchem Objekt sie gehört das sie dann Löschen kann.
Bei einer Funktion mag das anders aussehen.
Ich habe drei Python-Versionen installiert (2.5, 2.6, 3.1). Eine ist die default-Version meines Distributors, die beiden anderen habe ich von python.org und selbst gebaut. Und es funktioniert wie erwartet. Wenn es das bei dir nicht tut, solltest du dich an die Macher deines Systems wenden.
Und genau das kann man nicht von jedem Nutzer (nicht Entwickler!) erwarten. Python wird schließlich auch für GUI-Anwendungen verwendet, die sich auch an DAUs richten.
Aber von den Entwicklern Ubuntus, oder? Die müssen nämlich genau garnichts machen außer upstream mit dem Dreisatz abfrühstücken, allenfalls einen Symlink auf die gewünschte default-Version setzen.
Oder, der OP hat sich schlicht verfahren. Kann passieren.
Die müssen den Kram auch dann noch bei Sicherheitslücken patchen, wenn sich Upstream dafür nicht mehr interessiert. Und das für python2.3, python2.4, python2.5, python2.6, python3.0 und python3.1, Tendenz steigend. Andere Sprachen haben solche Probleme nicht.
Doch, durchaus. Ich kenne eigentlich keine Interpreter-Sprache die nicht das Problem haben das es scripte gibt die nicht auf allen Versionen laufen. Python ist nur mutiger gewesen, und entwickelt sich trotzt des alters noch dynamischer als manch eine andere Sprache.
Typische Beispiele für solche Probleme sind PHP, wo auch Minorversionen probleme erzeugen, und natürlich Perl, das verschiebt das Problem aktuell nur Jahr um Jahr.
Andere Sprachen wie Java, C, C++ und D haben nur das "Glück", dass deren Entwickler oder/und die Entwickler der Compiler ihrem Terminplan nicht hinterherkommen. (Warum auch immer) Da werden dann aus zwei Jahren Entwicklungszeit glatt mal 8-10 Jahre. Gut für die Programmierer, wenn es sich nur im Schönheitsoperationen handelt.
Wo sollte das Problem sein? Ubuntu liefert für beides Pakete mit, die du gleichzeitig installieren und nutzen kannst. Ich sehe da keine Probleme. Ich selbst nutze Anwendungen die auf 2.x aufbauen, und welche die auf python3 aufbauen. Zur selben Zeit.
HTH
Ein Symlink /usr/bin/python2 fehlt.
Die die du brauchst? War jetzt nicht soo schwer.
Wenn ich (mind.) Python 2.4 brauche, auf einem Zielsystem aber Python 2.5 installiert ist, läuft das Programm nicht, weil dort kein python-2.4 existiert. Und nicht jeder will jede Minor-Version von Python installieren, zumal manche Distributionen sie auch gar nicht anbieten und es auch gar nicht notwendig ist, wenn das Programm auch mit Python 2.5 laufen würde.
Konsequenz wäre wohl, jedes Programm als Download für jede Python-Version anzubieten mit dem einzigen Unterschied, dass die Versionsangabe im Shebang ne andere ist.
Im vorliegenden Fall hapert es beim OP mit dem parralelen Betrieb von Python-2.6.x und Python-3.x. Das geht auf die Kappe des OP oder der Ubuntu-Entwickler.
des OP, der Ubuntu-Entwickler, RED-Hat, SuSE, Debian, .... und als letztes Microfsoft.
Sorry, aber du kannst nicht jeder Firma und jedem Dau zumuten, das auf seinem System 18 Python-Versionen installiert sind, jeweils mit den entsprechenden 140 benötigten Zusatzbibliotheken. DAS ist meiner Meinung nach weltfremd! Und deshalb ist dieser Umstieg auf Python3 gescheitert!
Tschüss
Jürgen
Wenn du in meine Sätze also hineininterpretierst ich argumentiere pro Komp.-Brüche, liegst du falsch.
bitte verstehe es richtig, ich wollte nur die Problematik aufzeigen, weil weiter oben von Faulheit, mehreren Interpreter-Installationen und ähnlichen die Rede war. Mit meinen Beitrag wollte ich nur aufzeigen, das es evtl. einen besseren Weg gegeben hätte.
Eben weil Python so wichtig ist und so viele Projekte existieren, ist eine Rückwärtskompatibilität so wichtig. Es wäre m.M. nach dann wesentlich schneller vorangegangen.
Tschüss und einen schönen Abend noch
Jürgen
Es gibt Python-Anwendungen, die mit Python ab 2.4 funktionieren. Sie laufen auch mit 2.5 und 2.6. Wenn man jetzt python-2.4 im Shebang einträgt, zwingt man den Nutzer dazu, Python 2.4 zu installieren oder gar die Distribution zu wechseln, obwohl Python 2.5 es auch getan hätte.
Eine Programmiersprache ist da noch diffizieler. Aber das ist imho kein Problem. Wer zig Programme unter 2.x laufen hat, der soll diese doch ruhig noch weitere Jahre pflegen. Dann kann er ggf. paralle eine Portierung vornehmen, oder gar eine komplette Neuentwicklung.
Problematisch wird es doch nur für die Neuentwicklungen, die etwas benötigen, das es noch nicht portiert gibt! Allerdings lässt sich dieses Henne-Ei-Problem auch nicht mit der Brechstange lösen. Peux a peux werden viele Libs portiert oder es entstehen Neuentwicklungen, die diese Lücken füllen. So wird man früher oder später alle Bedürfnisse für 3.x erfüllen und immer mehr Entwickler werden umsteigen.
So lange sollte man eben die 2.xer Serie weiterpflegen und auf eine längere SIcht parallel als gleichwertig ansehen. Genau das passiert ja aber auch.
Und Guido hat sicherlich recht, wenn er nun die Stabilität und Perfektionierung anmahnt. Das gibt auch anderen Projekten wie Jython, PyPy usw. die Chance, die 3er Reihe von CPython einzuholen und näher an diesem Zweig dran zu sein.
Python3 ist im Grunde genommen tot oder besser gesagt nie wirklich geboren, im Sinne das es auch von jemanden benutzt wird. Das war ein ziemlicher Fehlgriff insbesondere weil man so ein Sprachänderung erst freigeben sollte, wenn wirklich alle Module auch angepasst sind und es auch für einen Entwickler Sinn macht sich über eine Portierung Gedanken zu machen.
Das war ein ziemlicher Fehlgriff insbesondere weil man so ein Sprachänderung erst freigeben sollte, wenn wirklich alle Module auch angepasst sind und es auch für einen Entwickler Sinn macht sich über eine Portierung Gedanken zu machen.
Nein, das macht überhaupt keinen Sinn! Die Core-Module sicher, aber die Standard-Lib war ja vollständig. Aber 3rd Party Module können ja erst dann auf Python 3 migrieren, sobald es eine finale Version gibt. Oder würdest Du deine App anpassen, wenn die Lib nicht stabil ist? Zudem bewirkt ein Release natürlich auch Aufmerksamkeit. Nein, nein, das war schon ein richtiger Schritt. Dass manche Dinge wie WSGI-Spec noch nicht auf Python 3 zugeschnitten sind, ist natürlich unglücklich. Aber so etwas passiert eben bei großen Projekten.
ändern und die Arbeit anderer damit zunichte machen.Damit sägt
man sich nur selbst den Ast ab, auf dem man sitzt.
Möge diese Botschaft auch bei Projekten wie KDE oder Qt
ankommen.
Möge diese Botschaft auch bei Projekten wie KDE oder Qt
ankommen.
Ähem... Speziell bei KDE gibt es zig Parallelen zu Python! Sicherlich spielst Du auf KDE 4 an; genau dieser Wechsel ist ja mit dem Schritt von Python 2 auf 3 super zu vergleichen. Bei Qt war der Sprung von 3 auf 4 sicherlich ebenfalls groß, aber eben auch berechtigt.
In Python 3 sind nun einmal viele Dinge gerade gerückt worden, die im 2er Ast gestört haben und nun endlich aufgrund der Nicht-Rückwärtskompatibilität erledigt werden konnten. Bei jedem großen Projekt stößt man nun einmal an Grenzen. Da ist ein harter Wechsel oftmals notwendig. Wo genau siehst Du nun also den markanten Unterschied zu KDE und Qt?
Es geht auch anders, siehe PHP