Hallo zusammen,
ich bin durchaus erfahrener Python 2.7-Programmierer und habe jetzt ein Thema mit der Portierung einer Bibliothek nach Python 3.3:
- Die Bibliothek ist teilweise in Libreoffice unter Linux integriert. Seit einiger Zeit geht das wirklich nur noch, wenn der Code in Python 3.3 geschrieben ist.
- Die Bibliothek macht intensiv Gebrauch von mechanize. Das ist nur für Python 2.7 verfügbar.
Ich hatte immer befürchtet, dass die Umstellung auf Python 3 irgendwelche "Haken" hat und deshalb habe ich bis heute nicht migriert. Jetzt sitze ich in einer klassischen Zwickmühle die einiges an Arbeit bedeuten wird. Ich sehe folgende Auswege:
- Warten auf den mechanize Port. Das kann dauern. Solange sind Teile meiner Bibliothe unbrauchbar, was inakzeptabel ist.
- Ersetzte mechanize durch ???. Ich kenne keine gute Alternative. Ich muss zahlreiche Webformulare ausfüllen. Der Weg bedeutet auf jeden Fall Arbeit.
- Umstellung der Libreoffice Python API um die Rückwärtskompatibilität wiederherzustellen.
Was meint ihr dazu?
Bastian
Python 2.7 nach Python 3.3
`lxml.html` kann Formulardaten parsen und die ausgefüllten Felder abschicken lassen. Guckst du hier. Vielleicht reicht das ja schon.
EDIT: Außerdem hat jemand `mechanize` geforkt und nen Python-3-Branch erstellt (Repo | Zusatzinfos des Autors).
Das sind aber alles Sachen, die ich selbst gerade per Google entdeckt habe. Hätte man *eigentlich* auch selber drauf kommen können, aber egal.
EDIT: Außerdem hat jemand `mechanize` geforkt und nen Python-3-Branch erstellt (Repo | Zusatzinfos des Autors).
Das sind aber alles Sachen, die ich selbst gerade per Google entdeckt habe. Hätte man *eigentlich* auch selber drauf kommen können, aber egal.
Ich habe natürlich gegoogelt. Der Author sagt auch selbst, das der mechnaize3-Port alles andere als fertig ist. Ich wollte mehr einen Erfahrungsaustausch anstoßen, was in diesem Fall der beste/schnellste/elegantete Weg ist? Vielleicht gibt es ja auch noch ganz andere Möglichkeiten, die ich noch nicht in Betracht gezogen habe.
-
BlackJack
@BastiL: Die Frage ist halt was am wenigsten Arbeit macht. Auf den `mechanize`-Port *warten* ist nicht akzeptabel, sagst Du. Vielleicht kannst Du beim portieren helfen, dann wird die Zeit kürzer. Oder Du testest `lxml.html`, ob das die Anforderungen erfüllt. Wenn auch Cookies verwaltet werden müssen, also sich das ein wenig mehr wie ein Browser verhalten soll, könnte man das `requests`-Modul noch in den Mix aufnehmen.
Ich würde das Mithelfen beim Python-3-Fork von `mechanize` favorisieren. Etwas in ähnlichem Umfang dürfte man für Python wohl kaum ein zweites Mal finden. Denn bevor man super-viel Zeit für die Anpassung des eigenen Codes an `lxml.html` und `requests` verwendet, kann man das genau so gut in die nötigen Python-3-Anpassungen von `mechanize` investieren.
Gut, man weiß vorab nicht unbedingt, was schneller geht. Im Falle eines Mithelfens bei `mechanize` hat man jedenfalls etwas auf Dauer Brauchbares für einen selbst und für die Community geschaffen. Wenn man ganz eigennützig ist, könnte man natürlich auch nur die Teile von `mechanize` anpassen, die man selbst benötigt. Ich weiß ja nicht, inwiefern ein paar Modulimporte eingespart werden können, wenn man bestimmte Funktionalität nicht benötigt. Sobald `mechanize` für dich wieder läuft, kannst du theoretisch auch die Unterstützung beenden und dich wieder um deinen eigentlichen "Kram" kümmern.
Gut, man weiß vorab nicht unbedingt, was schneller geht. Im Falle eines Mithelfens bei `mechanize` hat man jedenfalls etwas auf Dauer Brauchbares für einen selbst und für die Community geschaffen. Wenn man ganz eigennützig ist, könnte man natürlich auch nur die Teile von `mechanize` anpassen, die man selbst benötigt. Ich weiß ja nicht, inwiefern ein paar Modulimporte eingespart werden können, wenn man bestimmte Funktionalität nicht benötigt. Sobald `mechanize` für dich wieder läuft, kannst du theoretisch auch die Unterstützung beenden und dich wieder um deinen eigentlichen "Kram" kümmern.
@karolus:
Es ist eine selbst entwickelte Bibliothek die ein Ausgabe-Interface für das Tabellenkalkulationsmodul von Libreoffice hat. Ein Teil der Library lädt Daten aus dem Netz und ein anderer Teil kann diese in Tabellenblätter von Libreoffice schreiben. Der erste Teil nutzt mechanize sehr intensiv, der zweite müsste jetzt in Python 3.3. geschrieben werden.
Da mechanize weit öfter gebraucht wird als Libreoffice denke ich gerade darüber nach, das uno.py zu modifizieren, damit es wieder mit python 2.7 läuft.
Es ist eine selbst entwickelte Bibliothek die ein Ausgabe-Interface für das Tabellenkalkulationsmodul von Libreoffice hat. Ein Teil der Library lädt Daten aus dem Netz und ein anderer Teil kann diese in Tabellenblätter von Libreoffice schreiben. Der erste Teil nutzt mechanize sehr intensiv, der zweite müsste jetzt in Python 3.3. geschrieben werden.
Da mechanize weit öfter gebraucht wird als Libreoffice denke ich gerade darüber nach, das uno.py zu modifizieren, damit es wieder mit python 2.7 läuft.
@BastiL:
Falls das browserlike Argument für Dich zählt und du sowieso die Sache umschreiben musst, werfe ich mal noch Webkit in den Ring. Das kannst Du über Gtk und die Qt-bindings steuern und bedient dann auch Javascript-lastige Seiten korrekt.
Falls das browserlike Argument für Dich zählt und du sowieso die Sache umschreiben musst, werfe ich mal noch Webkit in den Ring. Das kannst Du über Gtk und die Qt-bindings steuern und bedient dann auch Javascript-lastige Seiten korrekt.
Das Thema ist hier auch behandelt:
https://bugs.launchpad.net/df-libreoffice/+bug/1222823
Die gepostete uno.py unterscheidet sich nur marginal, ich werde das mal testen.
https://bugs.launchpad.net/df-libreoffice/+bug/1222823
Die gepostete uno.py unterscheidet sich nur marginal, ich werde das mal testen.