2to3: doctest output anpassen?
Hi, ich möchte eine Bibliothek mit 2to3 'behandeln'. Mein Problem ist nun, dass (u.a.) doctests benutzt werden. Der eigentliche doctest-Code wird von 2to3 auch ganz zufriedenstellend portiert, nur leider der output nicht. Beispiel Python 2:
foo() u'foo'
Das "u" muss natürlich für Python 3 weg und das würde ich gerne irgendwie mit 2to3 machen. Allerdings scheint 2to3 sich nur um Code zu kümmern, nicht um die Ausgabe in den doctests. Gibt es eine Möglichkeit, dass ich mich irgendwo einklinke und einen eigenen "Fixer" schreiben kann? fs
Beispiel Python 2:
foo() u'foo'
Das "u" muss natürlich für Python 3 weg und das würde ich gerne irgendwie mit 2to3 machen. Allerdings scheint 2to3 sich nur um Code zu kümmern, nicht um die Ausgabe in den doctests.
Gibt es eine Möglichkeit, dass ich mich irgendwo einklinke und einen eigenen "Fixer" schreiben kann?
Wenn's nur um's testen geht, und nicht (so sehr) um Dokumentation, kannst Du schreiben
foo() == u'foo' True
Das wird dann von 2to3 richtig behandelt. Den Output kannst Du nicht so gut konvertieren. Eine Möglichkeit ist, im test runner sys.displayhook auszutauschen, sodass Unicode-Strings immernoch als u'' ausgegeben werden. Das ist natürlich gehackt. HTH, Martin
Am 09.03.2011 01:05, schrieb "Martin v. Löwis":
Wenn's nur um's testen geht, und nicht (so sehr) um Dokumentation, kannst Du schreiben
Für's Testen würde ich immer andere Tests vorziehen und bei den fraglichen Projekten scheint es für die doctests immer um die automatische Überprüfung von Beispiel-Code zu gehen. Insofern finde ich solche Hilfskonstrukte wie
foo() == u'foo' schon ziemlich hässlich.
Den Output kannst Du nicht so gut konvertieren. Eine Möglichkeit ist, im test runner sys.displayhook auszutauschen, sodass Unicode-Strings immernoch als u'' ausgegeben werden. Das ist natürlich gehackt.
Hacks sind erst mal ok (weil "output anpassen" per-se heuristisch/mit Annahmen belastet ist), aber "nicht so gut konvertieren" ist ja wohl etwas euphemistisch ausgedrückt ;-) Gibt es denn gar nichts, um direkt die doctest-Ausgabe Zeile für Zeile zu bekommen? Muss ich wieder mal selber ran ;-) fs PS: Ich (Python3-Laie!) halte es ja nach wie vor für einen Fehler, dass u'' in Python3 ungültig ist (und nicht einfach nur eine noop). Der "Python 2.7 + Python 3"-Konvertierungspfad überzeugt mich nicht wirklich, ich brauche "Python 2.4-2.7 + 3" – zumal im Moment Python 2.3 für mich immer noch wichtiger als Python 3 ist, was die geschäftliche Relevanz angeht.
PS: Ich (Python3-Laie!) halte es ja nach wie vor für einen Fehler, dass u'' in Python3 ungültig ist (und nicht einfach nur eine noop). Der "Python 2.7 + Python 3"-Konvertierungspfad überzeugt mich nicht wirklich, ich brauche "Python 2.4-2.7 + 3" – zumal im Moment Python 2.3 für mich immer noch wichtiger als Python 3 ist, was die geschäftliche Relevanz angeht.
Ich wünschte, die Leute würden aufhören, "Python 2.7 + Python 3" überhaupt als Konvertierungspfad zu erwähnen. "2.3-2.7 + 3" funktioniert auch; es gibt absolut keine Notwendigkeit, Python-2.3-Support aufzugeben, bloss weil Python-3-Support gewünscht ist. Ciao, Martin
Am 23.03.2011 20:36, schrieb "Martin v. Löwis":
Ich wünschte, die Leute würden aufhören, "Python 2.7 + Python 3" überhaupt als Konvertierungspfad zu erwähnen. "2.3-2.7 + 3" funktioniert auch; es gibt absolut keine Notwendigkeit, Python-2.3-Support aufzugeben, bloss weil Python-3-Support gewünscht ist.
Ich habe das nur erwähnt, weil ich im Kopf hatte, dass das der offiziell empfohlene Konvertierungspfad wäre. Ansonsten bin ich völlig einer Meinung mit dir – ich muss nur noch eine Lösung für "mein" doctest-Problem finden. fs
Felix Schwarz, 21.03.2011 19:40:
PS: Ich (Python3-Laie!) halte es ja nach wie vor für einen Fehler, dass u'' in Python3 ungültig ist (und nicht einfach nur eine noop).
Das macht ja nun gar keinen Sinn. Die Intention hinter Python 3 war von Anfang an, die Sprache aufzuräumen, und dabei explizit Abwärtskompatibilität hinten an zu stellen bzw. fallen zu lassen. Wie lange sollte denn eine solche Krücke aufrecht erhalten werden? Bis zu Python 4? Und warum sollte sie dann fallen gelassen werden, wo sie doch die ganze Zeit lang in Python 3 funktioniert hat? Stefan
Am 23.03.2011 21:29, schrieb Stefan Behnel:
Felix Schwarz, 21.03.2011 19:40:
PS: Ich (Python3-Laie!) halte es ja nach wie vor für einen Fehler, dass u'' in Python3 ungültig ist (und nicht einfach nur eine noop).
Das macht ja nun gar keinen Sinn. Die Intention hinter Python 3 war von Anfang an, die Sprache aufzuräumen, und dabei explizit Abwärtskompatibilität hinten an zu stellen bzw. fallen zu lassen.
Wie lange sollte denn eine solche Krücke aufrecht erhalten werden? Bis zu Python 4? Und warum sollte sie dann fallen gelassen werden, wo sie doch die ganze Zeit lang in Python 3 funktioniert hat?
Meiner Meinung nach hätte es Migrationen wesentlich erleichtert – gerade, wenn doctests im Spiel sind. Und ich sehe nicht, inwiefern eine solche no-op die Sprache wesentlich verschlechtert hätte. Die Unterscheidung str/unicode musste natürlich weg, das ist klar, aber deswegen hätte man IMHO das u'' nicht komplett entfernen müssen. Sauberer wäre es gewesen, die Syntax "deprecated" zu machen und dann ggf. in der nächsten Major-Version zu entfernen. So funktioniert das doch normalerweise in Python. Anyway, die Diskussion ist müßig, denn es ist wie es ist und keine Argumentation hier wird irgendeine Auswirkung auf Python haben :-) fs
participants (3)
-
"Martin v. Löwis" -
Felix Schwarz -
Stefan Behnel