PyQt4 oder 5?

Python und das Qt-Toolkit, erstellen von GUIs mittels des Qt-Designers.
Hellstorm
User
Beiträge: 231
Registriert: Samstag 22. Juni 2013, 15:01

BlackJack hat geschrieben: 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.
BlackJack hat geschrieben: 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?
BlackJack hat geschrieben: 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.
BlackJack hat geschrieben: 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 :D
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
User
Beiträge: 231
Registriert: Samstag 22. Juni 2013, 15:01

BlackJack hat geschrieben: 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.
BlackJack hat geschrieben: 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?
Benutzeravatar
snafu
User
Beiträge: 6731
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Helstorm hat geschrieben: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.
lackschuh
User
Beiträge: 281
Registriert: Dienstag 8. Mai 2012, 13:40

Hallo

Mal zurück zum Thema:

Ich nutze z.Z. pyqt4 und python 2.7 auf Win 7.
Auf der Herstellerseite steht:
PyQt v5.0 has been released. This is a major new release that supports Qt v5.
Python v3, v2.7 or v2.6 are supported
Nun aber ist auf der Downloadseite bei den Win installern Python 3.3 integriert. Wie bringe ich nun pyqt4 auf pyqt5 ohne auf python 3 umzusteigen?

mfg
BlackJack

@lackschuh: Gar nicht. Oder Du kompilierst Dir PyQt5 unter Windows selbst. Also gar nicht. :-)
Antworten