Python 2 und 3...

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Obwohl ich bei python-creole schon immer 2 und 3 unterstütze, bin ich meist mit Python 2 Unterwegs...

Nun hab ich zum ersten mal 2to3 genutzt und damit DragonPy angepasst. Funktioniert eigentlich ganz gut.
Hab zuerst einen branch gemacht und alles darin vorgenommen. Nach dem alles Läuft einen merge gemacht. Das sind dann die nötigen Änderungen: https://github.com/jedie/DragonPy/compa ... 43...2and3

Ich will 2 und 3 gleichzeitig unterstützten. Ich denke das macht aktuell am meisten Sinn, oder?

Ich hab dazu nun kein six.py beigepackt. Denn die Imports mache ich lieber selber und ansonsten braucht ich aus six.py nur das:

Code: Alles auswählen

PY2 = sys.version_info[0] == 2
PY3 = sys.version_info[0] == 3
if PY3:
    string_types = str,
else:
    string_types = basestring,
(s. https://github.com/jedie/DragonPy/blob/ ... ib2and3.py )


So richtig Aufwendig was das nun nicht. Deswegen frage ich mich, ob ich nicht generell alles mit den __future__ imports machen sollte:

Code: Alles auswählen

from __future__ import absolute_import, division, print_function, unicode_literals

Wie seht ihr das Python 2 und 3 Thema aktuell so?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Ich habe neulich mal wieder Python 3 probiert und bin auch prompt auf die Fresse gefallen weil Dateinamen, und damit viele Kommandozeilenargumente unter Unix/Linux nun mal Bytefolgen sind und kein Text. Bin dann für das Skript entnervt wieder auf 2.7 gegangen. Von wegen das mit Unicode ist alles viel einfacher unter 3. Passend dazu ein Blogbeitrag von Armin Ronacher a.k.a. mitsuhiko: Everything you did not want to know about Unicode in Python 3.

Im Moment bin ich eher mal wieder pessimistisch und hoffe das Python 4 vielleicht brauchbarer wird. :-) Ich sehe jedenfalls noch nicht den Zeitpunkt an dem ich mir konkrete Gedanken mache meine Projekte, insbesondere auf Arbeit, von 2 weg zu portieren. Selbst parallele Unterstützung macht noch keinen Sinn.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

absolute_import, division und print_function macht definitiv Sinn. Division im besonderen da wenn man da nicht konsequent ist sich sehr leicht subtile Bugs einbaut.

unicode_literals hingegen ist eine sehr schlechte Idee. Blackjack hat da einige gute Gründe genannt, in diesem Thread finden sich weitere. Insbesondere Django hat damit einiges kaputt gemacht.

Außerdem gibt es immernoch Probleme mit Python 3 wie z.B. dass man von dict nicht mehr erben und alle Methoden in Python überschreiben kann, da sich die .keys(), .values() und .items() Methoden nicht in Python Code implementieren lassen.

Wenn man Python 3 unterstützen will, empfiehlt es sich ausschliesslich Python 2.7 und Python >= 3.3 zu unterstützen. Desweiteren würde ich ganz stark von Sachen wie PY3 Konstanten oder Fallback Importen abraten. Schau dass du Kompatibilitätskram möglichst in einem Modul isolierst damit du ihn recht problemlos auch wieder los werden kannst. Wenn du Spezialfälle einbauen musst, die sich nicht praktikabel isolieren lassen, mach den Python 2 Weg zum Spezialfall (eine PY2 Konstante ist anders als eine PY3 Konstante hier sinnvoll) und Python 3 zum default.

Bei einem guten Port solltest du dein Kompatibilitätsmodul und alle Referenzen und Importe daraus entfernen können um Python 2 nicht mehr zu unterstützen, was übrig bleibt sollte Python 3 sein.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Generell setzte ich mindestens Python 2.7 vorraus. Das macht alles einfacher und z.B. ist in Debian wheezy (stable) "schon" 2.7 drin.
DasIch hat geschrieben:Desweiteren würde ich ganz stark von Sachen wie PY3 Konstanten oder Fallback Importen abraten. Schau dass du Kompatibilitätskram möglichst in einem Modul isolierst damit du ihn recht problemlos auch wieder los werden kannst.
Aber die six Lösung zu Importen bringt es doch auch nicht. Ist zwar zentral in six.py geregelt, aber wenn ich Python 2 dann fallen lasse, will ich ja auch six.py löschen. Also muß ich dann auch überall die six importe ändern :K

Momentan denken ich, werde ich erstmal versuchen nach Python 3 Art zu importieren und als Fallback dann der Python 2 import.

Bei einem Modul:

Code: Alles auswählen

try:
    import queue # Python 3
except ImportError:
    import Queue as queue # Python 2
Wenn es mehrere Module sind, dann Behandele ich die einfach zusammen, (natürlich nur bei std-lib) z.B.:

Code: Alles auswählen

try:
    # Python 3
    import tkinter
    from tkinter import filedialog
    from tkinter import messagebox
    from tkinter import scrolledtext
except ImportError:
    # Python 2
    import Tkinter as tkinter
    import tkFileDialog as filedialog
    import tkMessageBox as messagebox
    import ScrolledText as scrolledtext
six.py hat natürlich den Vorteil, das man z.B. bei tkinter alles "normal ansprechen" kann. Also: würde das IMHO gehn:

Code: Alles auswählen

from six.moves import tkinter

foo=tkinter.filedialog(...)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

jens hat geschrieben:Generell setzte ich mindestens Python 2.7 vorraus. Das macht alles einfacher und z.B. ist in Debian wheezy (stable) "schon" 2.7 drin.
DasIch hat geschrieben:Desweiteren würde ich ganz stark von Sachen wie PY3 Konstanten oder Fallback Importen abraten. Schau dass du Kompatibilitätskram möglichst in einem Modul isolierst damit du ihn recht problemlos auch wieder los werden kannst.
Aber die six Lösung zu Importen bringt es doch auch nicht. Ist zwar zentral in six.py geregelt, aber wenn ich Python 2 dann fallen lasse, will ich ja auch six.py löschen. Also muß ich dann auch überall die six importe ändern :K
Stimmt, allerdings musst du eben *nur* diese importe ändern, welche sich problemlos greppen lassen.
Bei einem Modul:

Code: Alles auswählen

try:
    import queue # Python 3
except ImportError:
    import Queue as queue # Python 2
Hast du erstmal Code in dieser Form über das Projekt verstreut, wird ist es wesentlich schwerer alle diese Importe zu finden. Außerdem kannst du dir sicher sein, dass wenn du six entfernt hast und keine ImportErrors bekommst du tatsächlich auch alle diese Importe gefunden hast.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Naja, wenn das der einzige Grund ist... 1. bleibt Python 2 uns sicherlich noch einige Jahre erhalten... 2. kann ich auch einfach nach "^except ImportError:$" suchen und das löschen. Dann kommen die Import-Fehler von alleine... Also ich denke finden kann man das so oder so...

Was anderes: Was haltet ihr denn von http://python-future.org/ ?!? Siehe auch die FAQ: http://python-future.org/faq.html

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

DasIch hat geschrieben:unicode_literals hingegen ist eine sehr schlechte Idee.
Das erscheint mir langsam auch so... Mehr Information auch hier: http://python-future.org/imports.html#s ... e-literals

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten