PyQt4 oder 5?

[Hellstorm]

Hallo,

ich habe zwar schon in die Suchfunktion benutzt, aber man kann nicht wirklich nach „PyQt 5“ suchen. Zu PyQt gibt es ja Unmengen an Ergebnissen.

Naja, ich bin gerade ein wenig verwirrt, was ich denn installieren soll. Python 3.3 steht für mich schon mal fest, da vernünftige Unicode-Unterstützung für mich ganz wichtig ist. Ich bin nur bei PyQt verwirrt.

Also so wie ich das auf der Riverbank-Seite sehe, gibt es dort folgende Auswahl:

PyQt4-4.10.2-gpl-Py3.3-Qt4.8.4-x64.exe
PyQt4-4.10.2-gpl-Py3.3-Qt5.0.2-x64.exe
PyQt5-5.0-gpl-Py3.3-Qt5.0.2-x64.exe

Also anscheinend gibt es einmal PyQt 4 für Qt 4.8.4 und für Qt 5.0.2, und dann gibt es noch einmal PyQt 5 für Qt 5.0.2. Aber was ist da der Unterschied zwischen PyQt 4 für Qt 5.0.2 und PyQt 5 für Qt 5.0.2?

Da ich mich nicht unbedingt noch an alte Versionen klammern möchte, würde ich jetzt einfach das dritte installieren – Das scheint mir das aktuellste zu sein. Ist das denn zu empfehlen oder gibt es massive Gründe, die dagegen sprechen?

Danke!

[BlackJack]

@Helstorm: Python 2.x hat auch vernünftige Unicode-Unterstützung.

[EmaNymton]

Also anscheinend gibt es einmal PyQt 4 für Qt 4.8.4 und für Qt 5.0.2, und dann gibt es noch einmal PyQt 5 für Qt 5.0.2. Aber was ist da der Unterschied zwischen PyQt 4 für Qt 5.0.2 und PyQt 5 für Qt 5.0.2?

Ich hoffe, das beantwortet deine Frage

http://pyqt.sourceforge.net/Docs/PyQt5/ ... on-numbers

[Hellstorm]

@Helstorm: Python 2.x hat auch vernünftige Unicode-Unterstützung.

Naja, aber immer u"..." schreiben zu müssen ist mir zu umständlich und entspricht mir nicht mehr ganz dem Zeitgeist Bin ein Fan von Sachen wo einfach alles out of the box in Unicode läuft.

@EmaNymton
Ah, danke! Wusste ich nicht

[BlackJack]

@Helstorm: Das zusätzliche u ist Dir zu umständlich? Und das auch nur bei literalen Zeichenketten die etwas ausserhalb von ASCII enthalten. Kein wirklich überzeugendes Argument. Ausserdem könnte man auch einfach ``from __future__ import unicode_literals`` zur Vorlage für Moduldateien hinzufügen.

[Hellstorm]

Also meine Programme sind meist sehr multilingual, deswegen finde ich das schon echt wichtig. Geht ja auch um andere Sachen, wie z.B. dass man im Header eben nicht die Kodierung angeben muss und auch Sachen auf die ich bis jetzt noch nicht gestoßen bin

Aber geht mir halt auch ums Prinzip, da ich gerne Programme nutze, wo Unicode wirklich schon die Standardeinstellung ist. Finde es immer sehr doof, wenn man sich wegen Unicode derart umstellen muss, obwohl es für alle Beteiligten besser wäre, wenn überall Unicode benutzt würde.

Btw: Kann man meinen Benutzernamen eigentlich auf Hellstorm ändern? Habe bei der Accounterstellung ein „l“ vergessen

[BlackJack]

@Helstorm: Wenn die Programme multilingual sind, dann ist das doch noch weniger ein Argument weil dann im Quelltext in der Regel alles auf Englisch ist, also ASCII ausreicht, und die Übersetzungen sowieso in Datendateien ausgelagert werden.

Der Kodierungskommentar wird auch von der Dateivorlage für neue Module ohne zusätzlichen Aufwand erledigt.

Egal was literale Zeichenketten per Voreinstellung für einen Typ haben, man muss sich in jedem Fall an den „Übergängen” Gedanken um das en- und dekodieren machen. Wobei ich die implizite Kodierung bei Python 3 gruselig finde — die wiederholen an der Stelle den Fehler den Java macht. Und das `sys.argv` automagisch dekodiert wird macht Python 3 für mich für einige Skripte schlicht unbrauchbar.

[Hellstorm]

@Helstorm: Wenn die Programme multilingual sind, dann ist das doch noch weniger ein Argument weil dann im Quelltext in der Regel alles auf Englisch ist, also ASCII ausreicht, und die Übersetzungen sowieso in Datendateien ausgelagert werden.

Ne, ich meinte das eher so, dass die Programme auch gerne fremde Zeichen verarbeiten, nicht nur anzeigen. Meine letzte Anfrage („Problem mit der get-Methode eines Wörterbuches“; siehe auch „Kleiner Zahlenkonverter”) sollte nämlich eigentlich eher so aussehen:

Code: Alles auswählen

string = "100万"
nummern = {"万":10000}

Klar könnte ich das auch alles mit u"万" machen, allerdings ist es so wesentlich einfacher: 万 ist ja im Endeffekt von der (linguistischen) Theorie auch nichts anderes als ein a. Wieso sollte man das dann in ein "..." und zum anderen ein u"..." aufteilen? Computertechnisch ist das natürlich was anderes, allerdings interessiert mich sogesehen als Python-Nutzer ja nicht, wie das intern abläuft. Schon Programmiersprachen wie C abstrahieren doch bereits von den unterliegenden Zeichenkodierungen (In C wird ja ein „a“ automatisch in eine 97 umgewandelt, und man muss nicht bei jedem String eine Folge von Zahlen eingeben), dann gilt das doch erst recht bei interpretierten Sprachen wie Python, die ja gerade den ganzen Klumpatsch mit Compilern usw. verstecken. Ich bin mir auch nicht sicher (habe es allerdings nicht ausprobiert), ob man in Python 2 z.B. gezielt nach einem Nicht-ASCII-Zeichen in einem String suchen kann: Das da oben sind ja z.B. drei Bytes, allerdings trotzdem nur ein Zeichen. Ich weiß nicht, ob sowas nicht Probleme verursacht. Das sind einfach so Sachen, die durch eine komplette Unicode-basierung besser ist (meiner Meinung nach).

Man darf ja auch nicht vergessen, dass Python auch mal in anderen Ländern benutzt wird, wo die Leute eben kein lateinisches Alphabet benutzen. Unsereins kann ja auch Variablennamen einfach in Deutsch schreiben (Nur halt die Umlaute und das ß weglassen), aber wenn z.B. ein Japaner so etwas schreiben möchte, dann ist es eben nicht so einfach. Mit Python 3 kann er halt einfach folgendes schreiben:

Code: Alles auswählen

名前 = "田中" #name = "Tanaka"
print(名前) #print(name)

Das ist meiner Meinung nach besonders auch für Einsteiger sinnvoll, denen man dann nicht erst „Du musst jetzt alles in Englisch schreiben, weil das Programm kein Japanisch unterstützt“ verklickern muss. Besonders wenn das Programm nur inländisch genutzt wird, oder sogar nur für sich selber: Wieso sollte man dann zwanghaft etwas in einer Fremdsprache schreiben?

Man muss sich ja mal anschauen, was es früher bei Webseiten, in Textverarbeitungen, in ganz normalen Programmen für Probleme gab, wenn man mal exotische Zeichen genutzt hat (Das beschränkt sich übrigens nicht nur auf Japanisch wie in meinem Beispiel, schon die Anführungszeichen („“), die ich hier nutze, sind ohne Unicode nicht möglich. Auch korrektes Englisch ist eigentlich mit ASCII nicht darstellbar). Das hat sich ja erst in den letzten 5–10 Jahren geändert, seitdem sich Unicode in den meisten Fällen als Standard durchgesetzt hat. Heutzutage kann man ohne Probleme in Dateinamen, auf Webseiten oder in Word-Dokumenten Deutsch, Japanisch und Arabisch mischen, ohne das irgendwie erst besonders „ankündigen“ zu müssen. Und da frage ich mich, wieso sich der Prozess nicht auch auf Programmiersprachen erstrecken soll – da kommen ja auch natürliche Sprachen zur Anwendung, und die sind nicht mit ASCII darstellbar.

Daher bin ich eigentlich knallhart dafür, jedes Dokument in jeder Anwendung immer grundsätzlich als UTF-8 zu speichern. Im allerbesten Fall (gehen wir mal 30 Jahre in die Zukunft) wird es keine anderen Kodierungen mehr geben und Zeichensalat gehört der Vergangenheit an.

[Sirius3]

Problematisch wird es halt, wenn man Sprachen nimmt, deren Schreibrichtung von der amerikanischen abweicht:

Code: Alles auswählen

تسعة=9
print(تسعة/2)
三=3
print(تسعة/三)

Was wird jetzt durch was geteilt?

Ganz zu schwiegen von den Zeichen, die identisch aussehen, aber doch verschieden sind:

Code: Alles auswählen

>>> Α=3;A=4
>>> print(Α,A)
3 4

Aus gutem Grund hat alles außerhalb von ASCII nichts im Programm-Code verloren. Für Meldungen gibt es i18n-Methoden, die das Problem sauber trennen. Unicode-Unterstützung ist wichtig, aber nur in der Datenverarbeitung.

[BlackJack]

@Helstorm: Wie gesagt ein einfacher `__future__`-Import reicht, dass man in dem Modul kein u mehr voranstellen muss. Wobei Du schon wieder sagst es wäre „wesentlich einfacher” "万" statt u"万" zu schreiben. Das überzeugt mich nicht, dass das Tippen eines u es im Gegenzug deutlich schwieriger machen soll.

Wieviele Bytes u"万" im Quelltext belegen ist doch egal. Es ist ein Unicode-Codepoint. Wobei man aufpassen muss: Unicode-Zeichenketten bedeuten nicht, das zwangsläufig ein Zeichen auch ein Codepoint ist. `len()` muss also nicht die Anzahl der Zeichen in einer Unicode-Zeichenkette liefern. Und dass das nicht nur ein theoretisches Problem ist, kann man zum Beispiel bei etwas alltäglichem wie Dateinamen mit Umlauten unter MacOS sehen. Da kann ein ``'ä' in filename`` auch unter Python 3 als Ergebnis `False` haben, auch wenn in `filename` tatsächlich ein ä enthalten ist!

Lokale Sprache ist IMHO kein Argument weil die Sprache selbst und die Dokumentation in Englisch sind. Wenn man ernsthaft programmieren will, dann kommt man um Englisch schlicht und ergreifend nicht herum.

Bei Bezeichnern die nicht in Englisch sind, beschränkt man die Gruppe der Leute die damit etwas anfangen können. Nur inländisch benutzt ist auch kein Argument. Das kann dann niemand lesen, warten, verbessern, der die Sprache nicht kennt. Damit schliesst man von vornherein aus, dass das jemals ohne vorher komplett überarbeitet zu werden, über diese Sprachbarriere hinaus verwendet werden kann.

In Dateinamen kann man nicht problemlos beliebige Zeichen verwenden. Da machen einem noch alte Dateisysteme und Archivformate Probleme. Unix hat traditionell Dateinamen die aus Bytefolgen bestehen und nicht aus Zeichen. Es ist also kein Problem Dateinamen in unterschiedlichen Kodierungen im gleichen Verzeichnis zu haben. Genau da fangen dann meine Probleme mit Sprachen und Bibliotheken an, die das einfach pauschal in Unicode umwandeln wollen — das geht nämlich nicht verlustfrei.

Bei Programmiersprachen kommen nicht wirklich natürliche Sprachen zur Anwendung. Die Schlüsselworte sind in der Regel aus dem Englischen entlehnt — das war es dann aber auch schon.

UTF-8 finde ich auch eine schicke Sache. Deswegen ärgert es mich auch, dass Python 3 das nicht macht. Stattdessen kann man ein Programm haben, das Unicode in einer Textdatei schreibt, ohne das man sich um die Kodierung kümmern muss. Das selbe Programm kann die selbst geschriebene Datei aber nicht mehr einlesen wenn man etwas an der Umgebung ändert. Zum Beispiel das Programm und die Datei 1:1 auf ein anderes Betriebssystem überträgt. Das bedeutet letztendlich, dass man genau wie bei Python 2 an den Grenzen zur Aussenwelt immer explizit (de)kodieren muss. Also kein Unterschied zu Python 2.

Der Zeichensalat wird durch UTF-8 nicht automatisch der Vergangenheit angehören. Es wird weiterhin Unmengen an Daten geben die nicht UTF-8 kodiert sind. Mir kommen heute noch ab und zu Textdateien mit Kodierungen aus der DOS-Zeit unter.

[Hellstorm]

Problematisch wird es halt, wenn man Sprachen nimmt, deren Schreibrichtung von der amerikanischen abweicht:

Code: Alles auswählen

تسعة=9

print(2/تسعة)
三=3
print(تسعة/三)

Was wird jetzt durch was geteilt?

Das stimmt. Man könnte allerdings eventuell jedes Wort „in sich“ als abgeschlossene Einheit betrachten. Das würde bedeuten, dass تسعة nur in sich selber von rechts nach links läuft, der gesamte Quellcode allerdings nicht verändert wird. Das ist ja auch schon nicht möglich, weil Python ja fast durchgängig englische Bezeichner verwendet. Das obige Beispiel würde daher doch eher so aussehen:

Code: Alles auswählen

تسعة ‎= 9
print(تسعة‎/2)
三 = 3
print(تسعة/三)

Ich sehe nicht, wo jetzt hier etwas problematisch sein sollte. Das ist alles ganz eindeutig Variablenname = Wert, auch nicht anders, als wenn man das jetzt auf Deutsch/Englisch schreiben würde.

Ganz zu schwiegen von den Zeichen, die identisch aussehen, aber doch verschieden sind:

Code: Alles auswählen

>>> Α=3;A=4
>>> print(Α,A)
3 4

Man muss diese ja nicht verwenden. Es könnte auch programmiersprachenintern Listen geben für Zeichen, die gleich aussehen (Ist ja in Unicode ja auch schon beschrieben). Dort würde dann ein Α und ein A als gleich behandelt.

Aus gutem Grund hat alles außerhalb von ASCII nichts im Programm-Code verloren. Für Meldungen gibt es i18n-Methoden, die das Problem sauber trennen. Unicode-Unterstützung ist wichtig, aber nur in der Datenverarbeitung.

Du hast dir hier jetzt aber die problematischsten Beispiele herausgesucht. Bei den allermeisten Buchstaben und Schriften ergibt sich in der Praxis aber kein Problem. Die meisten Schriften laufen einfach ganz banal von links nach rechts und sehen komplett anders aus als anderer Text.

Da kann ein ``'ä' in filename`` auch unter Python 3 als Ergebnis `False` haben, auch wenn in `filename` tatsächlich ein ä enthalten ist!

Dafür gibt es allerdings Unicode-Normalisierung. Das müsste natürlich schon in die zugrundeliegenden Bibliotheken eingearbeitet werden. Dann wäre es aber kein Problem, da ä und a+U0308 als gleich erkannt werden können.

Lokale Sprache ist IMHO kein Argument weil die Sprache selbst und die Dokumentation in Englisch sind. Wenn man ernsthaft programmieren will, dann kommt man um Englisch schlicht und ergreifend nicht herum.

Natürlich, aber mir geht es ja vor allem darum, dass man sich z.B. zwanghaft englische Namen für z.B. Variablen oder Funktionen überlegen muss.

Bei Bezeichnern die nicht in Englisch sind, beschränkt man die Gruppe der Leute die damit etwas anfangen können. Nur inländisch benutzt ist auch kein Argument. Das kann dann niemand lesen, warten, verbessern, der die Sprache nicht kennt. Damit schliesst man von vornherein aus, dass das jemals ohne vorher komplett überarbeitet zu werden, über diese Sprachbarriere hinaus verwendet werden kann.

Wenn ich ein Programm z.B. nur auf meinem Computer benutze, weil es genau einen Anwendungsfall für mich hat. Ja, dann werde ich es niemals jemand anderem geben, und ich sehe wirklich kein Problem, wieso ich da nicht Bezeichner in meiner Muttersprache nehmen sollte. Es wird ja nicht jedes Programm direkt als Open Source für die gesamte Menschheit im Internet veröffentlicht.

Ich wette auch, dass es viele Leute gibt, die Deutsch in ihren Programmen für die Bezeichner nutzen. Das darf auch nicht sein. Aber wieso machen es dann trotzdem viele Leute? Weil es für die Leute einfach unproblematischer ist, sich etwas in ihrer Mutterspracher ausdenken zu können anstatt immer zwanghaft auf Englisch zu denken. Man muss ja auch bedenken, dass Deutsch noch relativ nah an Englisch dran ist und es deshalb für unsereins nicht so problematisch ist. Bei vielen anderen Sprachen ist es nicht so einfach.

Und was ist denn z.B. mit irgendwelchen Schülern in Ländern, deren Sprache nichts mit Englisch zu tun hat? Die werden wohl kaum gut Englisch können, wenn sie erst ca. 12/13 Jahre alt sind. Aber möglicherweise können sie schon mit Programmieren anfangen. Dann würden sie sich für den Anfang einfach ein Buch (in ihrer Muttersprache) kaufen und das dann benutzen. Wenn ihnen dann aber gesagt wird, dass sie für alle Bezeichner usw. Englisch nutzen sollen, das sie nicht so gut können, dann werden sie vielleicht gleich das Handtuch werfen.

Klar bleibt bei Python und anderen Programmiersprachen immer noch viel auf Englisch übrig, selbst wenn es nur „print“ usw. ist. Da kann man ja auch nichts gegen machen, allerdings müssen solche Sachen ja auch nur abgeschrieben werden. Ich finde aber, dass überall, wo man sich selber etwas ausdenken muss, auch ruhig die eigene Sprache möglich sein sollte.

In Dateinamen kann man nicht problemlos beliebige Zeichen verwenden. Da machen einem noch alte Dateisysteme und Archivformate Probleme. Unix hat traditionell Dateinamen die aus Bytefolgen bestehen und nicht aus Zeichen. Es ist also kein Problem Dateinamen in unterschiedlichen Kodierungen im gleichen Verzeichnis zu haben. Genau da fangen dann meine Probleme mit Sprachen und Bibliotheken an, die das einfach pauschal in Unicode umwandeln wollen — das geht nämlich nicht verlustfrei.

Da wäre es doch sinnvoll, einfach mal alle Dateinamen im Dateisystem unter Unicode laufen zu lassen. Oder spricht da was dagegen?

Bei Programmiersprachen kommen nicht wirklich natürliche Sprachen zur Anwendung. Die Schlüsselworte sind in der Regel aus dem Englischen entlehnt — das war es dann aber auch schon.

Ich nenne allerdings Variablen, Klassen, Funktionen usw. alle irgendwie. Und wenn man da keine kryptischen Zeichenkombination wie x31dfvxa nutzt, dann ist das meistens auch irgendwie entfernt an die eigene Sprache angelehnt.

Wie gesagt, ich will ja nicht die Programmiersprachen an sich ändern. Wieso man allerdings nicht – soweit möglich – alles auf Unicode basieren lassen sollte, verstehe ich nicht.

[BlackJack]

@Helstorm: Wenn Du jedes Wort in sich abgeschlossen betrachtest bezüglich der Schreibrichtung, dann verstösst Du vielleicht gegen die Erwartung von Muttersprachlern, die natürlicherweise den ganzen ”Satz” in der für sie richtigen Reihenfolge schreiben und lesen möchten und nicht die einzelnen Worte in sich richtig, aber der Ausdruck dann falsch herum.

Ob Glyphen gleich aussehen hängt unter anderem von der verwendeten Schriftart für die Anzeige ab und nicht nur von den Zeichen selbst. Ausserdem haben sich die jeweiligen Autoren von Bibliotheken bei der Verwendung des grossen Omega und des Ohm-Zeichens vielleicht etwas dabei gedacht, und hätten nicht so gerne, dass die gleich behandelt werden. Sie haben ja auch jeweils andere Bedeutungen beziehungsweise hat das Symbol für Ohm eine klar definierte Bedeutung.

Zum Programmieren gehört auch, dass man ein Gefühl für ein gemeinsames Vokabular entwickelt, also nicht seine eigenen Funktionen entgegen den Mustern der Umgebung, also den vorhandenen Bibliotheken benennt. So etwas wie `get_*`, `set_*`, `is_*`, oder `has_*` sind zum Beispiel keine syntaktischen Vorgaben, aber etwas das bestimmte Erwartungen an die jeweiligen Attribute weckt. Und umgekehrt möchte man als Programmierer genau diese Erwartung an den Leser vermitteln wenn man solche Konventionen verwendet. Das gemeinsame Vokabular ist nun mal Englisch.

Zwanghaft englische Namen überlegen müssen klingt aufwändig. Ist es aber nicht. Der harte Teil ist in der Regel überhaupt einen guten, treffenden Namen zu finden. Den dann in einem (Online-)Wörterbuch nachzuschlagen ist nicht schwer. Und man lernt dabei auch noch ein bisschen Englisch. Was wichtig ist. Siehe auch „It's english, get over it”.

Ad-Hoc-Programme die nur mal eben irgendwo ein lokal, und vielleicht auch zeitlich, begrenztes Problem lösen, gibt es zwar. Aber die Erfahrung zeigt, das solche Lösungen deutlich länger leben können, und sich weiter entwickeln können, teilweise in Richtungen mit denen der Autor am Anfang nie gerechnet hat. Und solche Lösungen sind auch oft potentiell etwas was man dann doch mit anderen Teilen möchte, wenn man nämlich jemanden findet, der vor dem gleichen oder einem sehr ähnlichen Problem steht.

Ob Programmieranfänger gleich das Handtuch werfen oder erst später ist doch eigentlich egal, an Englisch kommen sie nicht vorbei. Man sollte das eher als Chance sehen Englisch zu lernen. Das Buch in der Muttersprache kann helfen um die Grundlagen zu lernen und die Konzepte besser zu verstehen, aber wenn man etwas nützliches/praktisches mit einer Programmiersprache anfangen möchte, wird man nicht um die Lektüre von Bibliotheksdokumentation herum kommen. Und die ist umfassend und aktuell nur auf Englisch verfügbar.

Was meinst Du mit „alle Dateinamen im Dateisystem unter Unicode laufen zu lassen”? Dagegen spricht, das gängige Dateisysteme gibt, die kein Unicode kennen, sondern nur Bytefolgen ohne eine Kodierungsangabe. Und damit kann man nicht feststellen wie der Dateiname als Unicode aussehen muss. Ähnliches gilt für Archivformate, die selbst wenn es mittlerweile Unicode-Unterstützung gibt, auch noch Bytefolgen erlauben.

[Hyperion]

UTF-8 finde ich auch eine schicke Sache. Deswegen ärgert es mich auch, dass Python 3 das nicht macht [ ... ]Das bedeutet letztendlich, dass man genau wie bei Python 2 an den Grenzen zur Aussenwelt immer explizit (de)kodieren muss. Also kein Unterschied zu Python 2.

Wie sollte / kann es denn sonst gehen? Intern ausschließlich mit UTF-8 codierten Strings arbeiten? Oder meinst Du, dass man per Default immer UTF-8 beim (De)codieren verwendet werden soll, anstelle des Plattform spezifischen Encodings?

Ich meine explizites (De)codieren ist schon alleine mal sinnvoll, damit ein Entwickler "merkt", dass man sich um Codierungen Gedanken machen muss. Es gibt ja durchaus Entwickler, die keine Ahnung von Encodings haben...

[BlackJack]

@Hyperion: Grundsätzlich UTF-8 hätte ich mir als Default gewünscht. Wird ja beim Quelltext auch so gemacht.

Da es auf der eigenen Plattform so wie es jetzt gelöst ist, ohne zu denken (fast) immer funktioniert, finde ich es ja schlecht. Es besteht einfach die Gefahr, dass es benutzt wird ohne sich über die Probleme im klaren zu sein. Vielleicht mag ich es auch nicht weil es mich an die Erfahrungen mit Java erinnert wo ich echt umfangreich mit Kommiltonen diskutieren musste dass es weder an mir noch an meinem Linux liegt, dass ihr unter Windows geschriebenes Programm + Daten bei mir nicht läuft. Das Argument war immer „bei mir läuft es, also kann ich da nix falsch gemacht haben.”

[Hyperion]

Das Argument war immer „bei mir läuft es, also kann ich da nix falsch gemacht haben.”

Ja, kenne ich auch. Es ist verdammt schlimm, wenn Entwickler gar nicht wissen *was* Encodings sind... genau deswegen kam ich ja einst zu diesem Board als unwissender Depp

[Hellstorm]

Zwanghaft englische Namen überlegen müssen klingt aufwändig. Ist es aber nicht. Der harte Teil ist in der Regel überhaupt einen guten, treffenden Namen zu finden. Den dann in einem (Online-)Wörterbuch nachzuschlagen ist nicht schwer. Und man lernt dabei auch noch ein bisschen Englisch. Was wichtig ist. Siehe auch „It's english, get over it”.

Naja, ich habe beim besten Willen keine Probleme mit Englisch. Wie gesagt, ich sehe nur kein Problem dabei, auch einfach Unicode-Bezeichner zu erlauben. Wenn dann in einem nächsten Satz mit einem „Das funktioniert zwar, aber benutz es nicht; wenn du es unbedingt benutzen willst, ist es dein eigenes Risiko“ gewarnt wird, dann ist das doch in Ordnung.

Ad-Hoc-Programme die nur mal eben irgendwo ein lokal, und vielleicht auch zeitlich, begrenztes Problem lösen, gibt es zwar. Aber die Erfahrung zeigt, das solche Lösungen deutlich länger leben können, und sich weiter entwickeln können, teilweise in Richtungen mit denen der Autor am Anfang nie gerechnet hat. Und solche Lösungen sind auch oft potentiell etwas was man dann doch mit anderen Teilen möchte, wenn man nämlich jemanden findet, der vor dem gleichen oder einem sehr ähnlichen Problem steht.

Naja, gut, aber selbst dann, kann ich dann nicht einfach ein Suchen/Ersetzen machen?

Ob Programmieranfänger gleich das Handtuch werfen oder erst später ist doch eigentlich egal, an Englisch kommen sie nicht vorbei. Man sollte das eher als Chance sehen Englisch zu lernen. Das Buch in der Muttersprache kann helfen um die Grundlagen zu lernen und die Konzepte besser zu verstehen, aber wenn man etwas nützliches/praktisches mit einer Programmiersprache anfangen möchte, wird man nicht um die Lektüre von Bibliotheksdokumentation herum kommen. Und die ist umfassend und aktuell nur auf Englisch verfügbar.

Klar, ich denke auch, dass man an Englisch nicht vorbeikommt. Ich finde es halt nur praktisch, wenn ich trotzdem meine eigene Sprache verwenden kann.

Was meinst Du mit „alle Dateinamen im Dateisystem unter Unicode laufen zu lassen”? Dagegen spricht, das gängige Dateisysteme gibt, die kein Unicode kennen, sondern nur Bytefolgen ohne eine Kodierungsangabe. Und damit kann man nicht feststellen wie der Dateiname als Unicode aussehen muss.

Naja, gut, aber Unicode ist ja nichts, was es erst seit gestern gibt. Wer nicht gerade 20-jährige Computer einsetzt, der wird wohl auch Unicode können. Ansonsten bin ich ja immer der Meinung, dass manche Systeme mal einen kleinen „Tritt in den Hintern“ bekommen sollten, damit Unicode unterstützt wird. Ich weiß noch, wann Debian auf Unicode umgestellt hat. Soweit ich weiß 2007 mit Debian 4, oder? Als Vergleich: Windows hatte schon mit NT 4.0 im Jahr 1996 (!) Unicode-Unterstützung.
Wenn Dateinamen nur Bytefolgen haben, dann muss da aber doch trotzdem irgendeine Kodierung angenommen werden, oder? Und da wäre es dann sinnvoll, dass von Betriebssystem/Dateisystemsicht einfach gnadenlos alles als Unicode angenommen wird. Unicode hat doch eh jede andere Kodierung in sich drinnen, so dass da kein Informationsverlust vorhanden ist. Wieso sollte man seine Dateinamen dann noch als ISO-8859-1 speichern?

@Hyperion
Naja, aber im Grunde ist es doch schon irgendwie wünschenswert, wenn das Wissen gar nicht erst notwendig ist. Klar, heutzutage braucht man es, aber im Grunde wäre es doch wirklich schön, wenn man sich darüber in Zukunft gar keine Gedanken mehr machen müsste, oder? Es sei denn, man befasst sich wirklich mit der Implementierung davon. Als „normaler“ Programmierer ist es allerdings doch im Grunde relativ uninteressant, da man ja eigentlich nur Text irgendwo speichern/verarbeiten möchte. Darum geht es mir im Grunde bei der ganzen Diskussion eigentlich nur

[BlackJack]

@Helstorm: Das ist keine Frage vom alter der Rechner oder des verwendeten Betriebssystems sondern der Daten und teilweise der Programme. Wie gesagt habe ich auch heute noch mit Daten, oft Textdateien und DBF-Datenbanken, zu tun, die Kodierungen aus der DOS-Ära verwenden.

Debian wurde auch nicht auf Unicode umgestellt, sondern UTF-8 wurde als Standardkodierung gewählt.

Warum muss *eine* Kodierung für Dateinamen angenommen werden? Und wie soll das Betriebssystem gnadenlos „Unicode” annehmen? Es gibt kein Unicode auf der Festplatte sondern grundsätzlich erst einmal nur Bytewerte und man muss die Kodierung davon kennen um die Bytefolgen als Unicode zu interpretieren, beziehungsweise Unicode in konkrete Bytefolgen zum speichern auf Festplatte zu konvertieren. Gleiches gilt auch für Netzwerkverbindungen oder so etwas wie serielle Schnittstellen. Da werden jeweils Bytes übertragen. Und wenn man Text übertragen möchte, müssen sich beide Seiten über die Kodierung einig sein, oder die Daten „blind” verarbeiten können. Unicode ist eine abstrakte Idee, um das zu speichern oder zu verarbeiten muss es irgendwie als Bytefolgen kodiert sein. Und dazu braucht man konkrete Kodierungen und Wege diese Information mit den Daten zu speichern und zu übertragen.

[Hellstorm]

Warum muss *eine* Kodierung für Dateinamen angeommen werden? Und wie soll das Betriebssystem gnadenlos „Unicode” annehmen?

Das Betriebssystem kann doch einfach sagen „Alles ist UTF-8 (oder 16 oder 32), es sei denn, es wird anders definiert“. Das ist doch in vielen Fällen sowieso schon der Fall, in XML, in Python 3 usw.

Es gibt kein Unicode auf der Festplatte sondern grundsätzlich erst einmal nur Bytewerte und man muss die Kodierung davon kennen um die Bytefolgen als Unicode zu interpretieren, beziehungsweise Unicode in konkrete Bytefolgen zum speichern auf Festplatte zu konvertieren. Gleiches gilt auch für Netzwerkverbindungen oder so etwas wie serielle Schnittstellen. Da werden jeweils Bytes übertragen. Und wenn man Text übertragen möchte, müssen sich beide Seiten über die Kodierung einig sein, oder die Daten „blind” verarbeiten können. Unicode ist eine abstrakte Idee, um das zu speichern oder zu verarbeiten muss es irgendwie als Bytefolgen kodiert sein. Und dazu braucht man konkrete Kodierungen und Wege diese Information mit den Daten zu speichern und zu übertragen.

Ja, jeder Text ist ja nur eine Abfolge von Zahlen, das ist mir auch bewusst. Dass kein „Unicode“ an sich irgendwo gespeichert wird, ist mir auch bewusst. Daher muss man bei jedem Text auf jeden Fall eine Kodierung annehmen: Ob es nun ASCII ist, UTF-8, UTF-16 oder auch was ganz inkompatibles, das ist doch egal. Aber da Unicode eben den Vorteil hat, dass es keine „konkurrierenden“ Zeichenkodierungen gibt, bzw. man sich nicht für eine Sprache entscheiden muss, ist eine Unicode-Kodierung doch sinnvoll, oder nicht? Wenn ich davon ausgehe, dass alle Dateinamen in einem Dateisystem als z.B. UTF-8 gespeichert sind, dann ist das doch nicht schlimm, oder?
Es ist natürlich sinnvoll, wenn im Dateisystem selber noch einmal ausdrücklich die Kodierung angegeben wird. So kann man dann auch ISO-8859-5 oder Shift_JIS o.ä. nutzen. Wobei ich da in vielen Fällen den Sinn nicht sehe, da das heutzutage ja alles nur Untermengen von Unicode sind.

Das Problem ist ja doch dann im Grunde nur, was ist, wenn keine Kodierung explizit angegeben wird. Der kleinste gemeinsame Nenner ist da ja immer noch überall ASCII, was ja auch nicht schlimm ist. Allerdings ist es doch im Grunde auch kein Problem, wenn bei immer mehr Übertragungswegen dann einfach UTF-8 angenommen würde. UTF-8 hat ja den Vorteil, dass es 100%ig kompatibel zu ASCII ist (bzw. ASCII ist ja im Grunde ein Teil von UTF-8), so dass weiterhin eine Übertragung nur mit ASCII-Zeichen vollkommen möglich ist. Und wenn jetzt jemand Nicht-ASCII-Zeichen überträgt, nimmt die Gegenstelle einfach UTF-8 anstatt von z.B. ISO-8859-1 o.ä. an.

Und wenn das z.B. über 20-30 Jahre gemacht wird, dann wird sich doch irgendwann einfach aus Gewohnheit mal herausgestellt haben, dass alle Übertragungswege UTF-8-basierend sind. Natürlich wird es immer noch alte Kodierungen geben, aber für die müsste man dann einfach manuell die Kodierung angeben.

Genau aus dem Grund finde ich aber Programme, die ihre Dateien standardmäßig als UTF-8 speichern, so begrüßenswert. Damit wird halt einfach ein Fakt geschaffen, so dass es in Zukunft (hoffentlich) wirklich selbstverständlich wird, überall Unicode verwenden zu können. Wenn es allerdings immer Programme gibt, die nicht standardmäßig Unicode verwenden (sondern z.B. ISO-8859-1), dann besteht immer das Risiko, dass der Ersteller davon keine Ahnung hat („Ich kann doch Deutsch schreiben, mehr brauche ich doch gar nicht“) und die Kodierung nicht auf UTF-8 umstellt. Genau das Problem hab ich doch bei vielen Webseiten gesehen. Da möchte ich dann „“ schreiben, und es geht wieder nicht, weil die Webseite nur unter ISO-8859-1 läuft, obwohl UTF-8 ja gar kein Problem wäre.

In diesem Forum geht es ja glücklicherweise, wobei ich nicht weiß, ob das daran liegt, dass jemand bei der Einrichtung das extra umgestellt hat oder weil phpBB automatisch in UTF-8 läuft.

Das ist einfach nur meine Begründung, wieso ich Python 3 ggü Python 2 bevorzuge. Es wird standardmäßig UTF-8 angenommen, was Fakten schafft und in Zukunft (20-30 Jahren) dann hoffentlich wirklich zu 99–100% Standard ist und man sich nicht verbiegen muss, um Unicode zu benutzen.

Oder wo liegt hier jetzt mein Denkfehler?

[snafu]

Oder wo liegt hier jetzt mein Denkfehler?

Ich sehe da keinen Denkfehler. Ich sehe auch keinen Denkfehler darin, den Leuten das Programmieren grundsätzlich in ihrer Sprache mit dem entsprechenden Zeichensatz möglich zu machen. "Schreib es lieber gleich in Englisch" ist IMHO eine sehr sinnvolle Konvention, aber es gibt auch Situation - insbesondere in Schulen oder Universitäten - wo man in Einführungsveranstaltungen den Lernenden eine freie Wahl lassen möchte, ob sie lieber Englisch oder die jeweilige Landessprache verwenden. Man muss gegenüber Anfängern meiner Meinung nach nicht noch zusätzliche Hürden durch eine selbst geschaffene Sprachbarriere aufbauen. Zumindest in diesem genannten Kontext überwiegen für mich die Vorteile des Lernerfolgs. Ab dem zweiten Semester / Halbjahr kann man dann theoretisch immer noch vorgeben, dass jetzt auf jeden Fall alles in Englisch geschrieben werden muss. Ein grundsätzliches (eher implizites) "Verbot" durch die Programmiersprache finde ich nicht so gut.

[BlackJack]

@Helstorm: Das kann das Betriebssystem sagen, tut es in gewisser Weise unter Linux auch. Nur muss das halt nicht mit der Realität übereinstimmen. Und genau da fangen die Probleme an. Solange nicht alle verwendeten Dateisysteme und -formate neben dem Text auch die Information enthalten in welcher Kodierung der vorliegt, muss man sich selbst aktiv mit Kodierungen auseinander setzen.

Selbst wenn nur Kodierungen verwendet werden, welche den gesamten Unicode-Bereich kodieren können, muss man auch speichern welche Kodierung konkret verwendet wurde. Denn es gibt da ja nicht eine Kodierung die alle verwenden. Und man würde letztlich den gleichen Fehler wiederholen den man bei ASCII und Co gemacht hat, dass man einfach davon ausgeht man wüsste schon was jetzt jeder verwendet und auch in alle Ewigkeit verwenden wird. Niemand wird einfache Textdateien anders als in ASCII schreiben. Ein paar Jahre später: Niemand wird was anderes als cp850 brauchen, oder die Dateien mit Regionen austauschen wollen die andere Kodierungen verwenden. Da müsste der normale Anwender ja 5¼"-Disketten per Post über Landesgrenzen hinweg verschicken. Dann kam Windows und cp1252. Da sind sogar Deine „” enthalten. Mehr wird kaum jemand brauchen. Und nun UTF-8. Das enthält alles was man jemals brauchen wird, und wird von nun an von jedem und bis in alle Ewigkeit verwendet. Wer's glaubt…

UTF-8 kann Bytewerte enthalten, die nicht in ASCII enthalten sind. Die würde ich also nicht als 100% kompatibel bezeichnen. ASCII ist eine Untermenge von UTF-8.

Bei Python 3 wird eben *nicht* standardmässig UTF-8 angenommen! Ausser beim Compiler für den Quelltext. Aber das finde ich jetzt echt nicht so weltbewegend, denn dafür verwende ich schon selbst UTF-8, beziehungsweise beschweren sich Python 2.6 und grösser wenn man keine Kodierung angibt. Da ist also immer sichergestellt, dass der Compiler das richtig interpretiert, solange der Programmierer weiss was er da tut. Bei allen anderen impliziten Konvertierungen wird nicht wie bei Python 2 erst einmal nur ASCII angenommen, so dass dem Programmierer das um die Ohren fliegt, wenn er etwas anderes in seinen Daten hat, sondern Python 3 verwendet hier still und leise die *Systemeinstellung*. Das heisst Leute die keine Ahnung von den potentiellen Kodierungsproblemen haben, bekommen das nicht wie bei Python 2 deutlich vor die Füsse geworfen, sondern es funktioniert scheinbar ganz einfach so. Das finde ich eine Verschlechterung der Unicode-Situation. Ich hätte mir ja *gewünscht* das Python 3 einfach UTF-8 annimmt wenn man nichts explizit angibt. Aber so muss man überall explizit Kodierungen angeben, wird aber nicht mehr so deutlich dazu gezwungen wie bei Python 2, so dass Anfänger da nichts von mitbekommen. Erst wenn es zu spät ist. Und dann können sie immer noch sagen „Ach aber bei mir funktioniert doch alles super.” Erinnert doch irgendwie an das „Ich verwende ISO-8859-15, was anderes brauche ich nicht.” Und letztendlich *ist* es das ja auch. Linux-Benutzer sind fein raus, weil die meisten Systeme heute auf UTF-8 setzen. Aber Windows-Benutzer können auf dem eigenen Rechner schon ins Messer laufen weil ein und das selbe Skript auf dem gleichen Rechner einmal in der Eingabeaufforderung und einmal als „Fensterprogramm” gestartet die eigenen Daten schon nicht mehr verstehen muss, weil beide Umgebungen eine andere Systemkodierung verwenden. Das ist doch Mist. Um dem zu entgegenzuwirken muss man genau die gleichen Massnahmen wie unter Python 2 ergreifen. Also sehe ich da bei Python 3 keinen Vorteil.