Python-3-Buch für Python 2.7?

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
deamon
User
Beiträge: 63
Registriert: Mittwoch 8. Oktober 2008, 11:14

Die Grundlagen von Python kenne ich zwar, aber ich will mein Wissen hier und da noch etwas vertiefen. Ich will Python 2.7 einsetzen (da WSGI mit Python 3 nicht so richtig kompatibel ist) und da in diese Version einiges von Python 3.x zurück portiert wurde, überlege ich, ob für meine Studien ein Python 2.(5|6)-Buch oder ein Python 3.(0|1)-Buch (ich habe Programming in Python 3)besser wäre.

Was haltet ihr zum Lernen von Python 2.7 für besser: ein Python-2-Buch oder ein Python-3-Buch? Über was würde man wahrscheinlich stolpern, wenn man Python-3-Wissen auf Python 2.7 anwendet?
Pa5tA
User
Beiträge: 21
Registriert: Sonntag 1. August 2010, 16:37

Die unterschiede zwischen Python3 und Python2 sind sehr gering. Ich hab Python3 gelernt, aber hab auch schon Sachen in Python 2 geschrieben. Das ist eigentlich kein Problem, es gibt so 5 bis 6 wichtige Unterschiede, aber ansonsten sind das nur klein Aenderungen in der Standardbibliothek. Die meistne von den Aenderungen sind aber sowieso schon in 2.7 enthalten (zumindest soweit ich weiss)
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

unicode vs. bytes ist schon eine sehr große Änderung.
deamon
User
Beiträge: 63
Registriert: Mittwoch 8. Oktober 2008, 11:14

DasIch hat geschrieben:unicode vs. bytes ist schon eine sehr große Änderung.
Das hat zwar weitreichende Konsequenzen, aber ansonsten ist die Änderung ja einfach zu verstehen.
Benutzeravatar
/me
User
Beiträge: 3555
Registriert: Donnerstag 25. Juni 2009, 14:40
Wohnort: Bonn

DasIch hat geschrieben:unicode vs. bytes ist schon eine sehr große Änderung.
Alle meine Programme unter (aktuell) Python 2.6 enthalten jetzt schon immer Folgendes:

Code: Alles auswählen

from __future__ import unicode_literals
from __future__ import print_function
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

/me hat geschrieben:
DasIch hat geschrieben:unicode vs. bytes ist schon eine sehr große Änderung.
Alle meine Programme unter (aktuell) Python 2.6 enthalten jetzt schon immer Folgendes:

Code: Alles auswählen

from __future__ import unicode_literals
from __future__ import print_function
Trotzdem hast du keine bytes wie in Python 3.x und die stellen das größte Problem dar da sie sich nicht mehr wie strings verhalten.
lunar

@DasIch: Das Problem ist allerdings nicht der "bytes"-Typ aus Python 3, sondern die idiotische implizite Konvertierung zwischen "str" und "unicode" in Python 2, wo man eigentlich nie sicher sein kann, ob man gerade mit Bytes oder mit Zeichen arbeitet.

Auch in Python 2 ist eine strikte Trennung zwischen unicode und str sinnvoll (e.g. frühzeitig dekodieren und intern nur unicode verwenden). Hält man sich daran, dann hat man in Python 3 auch kein Problem.
mutetella
User
Beiträge: 1695
Registriert: Donnerstag 5. März 2009, 17:10
Kontaktdaten:

lunar hat geschrieben:Auch in Python 2 ist eine strikte Trennung zwischen unicode und str sinnvoll (e.g. frühzeitig dekodieren und intern nur unicode verwenden). Hält man sich daran, dann hat man in Python 3 auch kein Problem.
Könntest Du das etwas konkretisieren oder mir vielleicht sogar das eine oder andere Codebeispiel geben?

Gruß
mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit ;-) )
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

mutetella hat geschrieben:
lunar hat geschrieben:Auch in Python 2 ist eine strikte Trennung zwischen unicode und str sinnvoll (e.g. frühzeitig dekodieren und intern nur unicode verwenden). Hält man sich daran, dann hat man in Python 3 auch kein Problem.
Könntest Du das etwas konkretisieren oder mir vielleicht sogar das eine oder andere Codebeispiel geben?
Wenn du mit Text arbeitest, dann wandle diesen so früh wie möglich in Unicode um.
Das Leben ist wie ein Tennisball.
lunar

@mutetella: Was soll ich da noch konkretisieren? „Frühzeitig dekodieren und intern nur unicode verwenden“ ist so konkret wie möglich, alles weitere ist anwendungsspezifisch. Es gilt halt, jegliche Eingabe aus der Umgebung (e.g. Dateien, Kommandozeilenargumente, Standardeingabe, usw.) direkt nach dem Erhalt anhand der passenden Kodierung (was manchmal problematisch sein kann) zu dekodieren, intern nur unicode verarbeiten, und erst kurz vor der Ausgabe (e.g. Standardausgabe, Dateien, usw.) wieder in bytes zu enkodieren, ebenfalls wieder mit der passenden Kodierung.
Antworten