Wieso benutzen fast alle hier im Forum Python 2.x wenn es schon Python 3.x gibt?
Gibt es irgendwelche Nachteile von Python 3.x ? :K :K :K :K
Python 2 vs Python 3
@fail
Weshalb nimmst Du an, dass "fast alle hier im Forum Python 2.x" verwenden?
Ja, es gibt Nachteile bei der Verwendung von Python 3.
Ja, es gibt Vorteile bei der Verwendung von Python 3.
Wie so oft: Es kommt darauf an...
mutetella
Weshalb nimmst Du an, dass "fast alle hier im Forum Python 2.x" verwenden?
Ja, es gibt Nachteile bei der Verwendung von Python 3.
Ja, es gibt Vorteile bei der Verwendung von Python 3.
Wie so oft: Es kommt darauf an...
mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
@fail
Was "die" machen, weiß ich natürlich nicht. Ich für meinen Teil starte Pythonskripte, die für Python 2 geschrieben wurden, mit Python 2 und Python 3 Skripte mit Python 3. Oder was meinst Du mit "Code konvertieren"...?
Hmm... ich weiß ehrlich gesagt nicht so richtig, was Deine Frage eigentlich ist. Vielleicht hilft Dir ja die Dokumentation weiter...
mutetella
Was "die" machen, weiß ich natürlich nicht. Ich für meinen Teil starte Pythonskripte, die für Python 2 geschrieben wurden, mit Python 2 und Python 3 Skripte mit Python 3. Oder was meinst Du mit "Code konvertieren"...?
Hmm... ich weiß ehrlich gesagt nicht so richtig, was Deine Frage eigentlich ist. Vielleicht hilft Dir ja die Dokumentation weiter...
mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
Ich habe Python 2, Python 3 und PyPy installiert. Den Code lasse ich jeweils mit der Python-Umgebung laufen für die er gedacht ist.fail hat geschrieben:Habt ihr beide Versionen installiert oder konvertiert ihr den Code bevor ihr in bei euch ausführt
Ich habe natürlich alten Code, der nicht 1:1 von Python 2 nach Python 3 übernommen werden kann. Ich versuche da allerdings größtmögliche Nähe herzustellen. Die Verwendung von 2to3 zeigt da einige Ansätze auf. Zusätzlich haben fast alle meine Programme im Header folgende Future-Importe die gewisse Änderungen aus Python 3 vorwegnehmen:
Code: Alles auswählen
from __future__ import unicode_literals
from __future__ import print_function
from __future__ import division
2to3 gibt Hinweise. Ich lasse das nicht vollautomatisch ändernd auf den Code los.DasIch hat geschrieben:Ich schreib Python 2.6/7, so dass es mit Python 3.3 kompatibel ist. 2to3 und unicode_literals sind imho eine recht schlechte Idee.
Welche Probleme siehst du mit unicode_literals? Ich empfinde den Umgang damit als sehr handlich.
Wie testest du dann dass der Code auf 2.x und 3.x funktioniert?/me hat geschrieben:2to3 gibt Hinweise. Ich lasse das nicht vollautomatisch ändernd auf den Code los.DasIch hat geschrieben:Ich schreib Python 2.6/7, so dass es mit Python 3.3 kompatibel ist. 2to3 und unicode_literals sind imho eine recht schlechte Idee.
Mit unicode_literals machst du dir native strings kaputt. PEP 414 erklärt dies ausführlich.Welche Probleme siehst du mit unicode_literals? Ich empfinde den Umgang damit als sehr handlich.
Ich passe aufgrund der Ergebnisse von 2to3 den Code unter Python 2 so an, dass er optimalerweise direkt mit Python 3 verwendet werden kann. Wo das nicht möglich ist muss ich den Code in zwei Varianten vorhalten und diese in der jeweiligen Umgebung testen.DasIch hat geschrieben:Wie testest du dann dass der Code auf 2.x und 3.x funktioniert?/me hat geschrieben:2to3 gibt Hinweise. Ich lasse das nicht vollautomatisch ändernd auf den Code los.
Was interessieren mich native strings? Das Handling von WSGI lasse ich mir natürlich von einem Framework abnehmen.DasIch hat geschrieben:Mit unicode_literals machst du dir native strings kaputt. PEP 414 erklärt dies ausführlich.
Ersteres ist ja schon unangenehm./me hat geschrieben:Ich passe aufgrund der Ergebnisse von 2to3 den Code unter Python 2 so an, dass er optimalerweise direkt mit Python 3 verwendet werden kann. Wo das nicht möglich ist muss ich den Code in zwei Varianten vorhalten und diese in der jeweiligen Umgebung testen.
Was interessieren mich native strings? Das Handling von WSGI lasse ich mir natürlich von einem Framework abnehmen.[/quote]DasIch hat geschrieben:Mit unicode_literals machst du dir native strings kaputt. PEP 414 erklärt dies ausführlich.
Wenn du mehr als nur die Überschrift liest, werden einige andere Beispiele genannt die nichts mit WSGI zu tun haben. Das Phänomen tritt zumindest so oft auf, dass man unicode_literals nicht uneingeschränkt empfehlen kann.
- pillmuncher
- User
- Beiträge: 1484
- Registriert: Samstag 21. März 2009, 22:59
- Wohnort: Pfaffenwinkel
Ich verwende 2.7 und neuerdings 3.3. Um Probleme zu vermeiden schau ich immer erst hier nach:
http://py3ksupport.appspot.com
https://python3wos.appspot.com
Und dieselbe Diskussion auf HackerNews:
http://news.ycombinator.com/item?id=4907755
http://py3ksupport.appspot.com
https://python3wos.appspot.com
Und dieselbe Diskussion auf HackerNews:
http://news.ycombinator.com/item?id=4907755
In specifications, Murphy's Law supersedes Ohm's.
Unter Python 3 hat man dann aber nichts anderes mehr.DasIch hat geschrieben:Wenn du mehr als nur die Überschrift liest, werden einige andere Beispiele genannt die nichts mit WSGI zu tun haben. Das Phänomen tritt zumindest so oft auf, dass man unicode_literals nicht uneingeschränkt empfehlen kann.
Anscheinend tritt im Kontext der von mir verwendeten und geschriebenen Software das Problem nicht auf, das andere mit Default-Unicode-Strings unter Python 2 haben. Wenn ich zudem in der Django-Dokumentation unter Porting to Python 3 die Empfehlung lese: "[Add] from __future__ import unicode_literals at the top of your Python modules – it’s best to put it in each and every module [...]", dann habe ich nicht das Gefühl, dass eine weitgehend nichttechnische Kontroverse zu dem Thema mich von der Verwendung von unicode_literals abbringen sollte.
Für mich überwiegen die positiven Aspekte, alleine deshalb weil für mich keine negativen Aspekte existieren.
@DasIch Ich kann Deinen Einwand ebenso wenig nachvollziehen wie /me. Native Strings lassen sich völlig unabhängig von "unicode_literals" immer mit "str()" erzeugen. In den seltenen Fällen, in denen native Strings zwingend notwendig sind, reicht diese Möglichkeit vollkommen aus.
Die Notwendigkeit von PEP 414 erschließt sich mir nicht.
Die Notwendigkeit von PEP 414 erschließt sich mir nicht.
@fail: Ich verwende Python 2 weil es immer noch bei vielen Linux-Distrubitionen und Webhostern das Standardpython ist und noch nicht alle Module und Pakete die ich so brauche für Python 3.x zur Verfügung stehen. Pypy und Jython sind ebenfalls noch auf dem Stand von Python 2. Ansonsten sehe ich nicht was mir Python 3 so tolles bringt, dass ich unbedingt jetzt schon wechseln müsste/wollte.
Irgendwie schafft die PSF es seit mehr als zwei Wochen nicht das Wiki wieder an den Start zu bringen (sind die tot‽), darum aus dem Archiv: Python2orPython3.
Irgendwie schafft die PSF es seit mehr als zwei Wochen nicht das Wiki wieder an den Start zu bringen (sind die tot‽), darum aus dem Archiv: Python2orPython3.
Zuletzt geändert von BlackJack am Freitag 25. Januar 2013, 19:45, insgesamt 1-mal geändert.
Grund: Dummer Tippfehler. Dank an /me für den Hinweis.
Grund: Dummer Tippfehler. Dank an /me für den Hinweis.