Umlaute in Pyscripter

[Kebap]

Hallo Leute!
Ich benutze gerne Pyscripter IDE unter Windows. Folgendes Problem aber:

Mein Programm:

Code: Alles auswählen

print "Umlaute: äöü ok"

Die Ausgabe:

Code: Alles auswählen

*** Remote Interpreter Reinitialized  ***
>>> 
Umlaute: ??? ok
>>>

Was zur Hölle? Ich habe schon ne Menge rumprobiert, aber auch "# -*- coding: utf-8 -*-" bringt keine Besserung.

[Hyperion]

Du musst wissen, welches Encoding die Shell verwendet. In diesem Encoding musst Du Deine Ausgaben absetzen.

Sofern Du die Datei als UTF-8 gespeichert hast, ist bewiesen, dass die Shell ein anderes Encoding verlangt.

[snafu]

Ich kenne PyScripter nicht, habe daher mal gegoogelt. Hast du das schon probiert?

Tools, Options, IDE Options, Default File Encoding for new files.
Also mannually, Edit, File Format.
Read also the help file topic on File Encodings.

[Kebap]

Ich habe die Datei jetzt als UTF-8 gespeichert. Vorher war ANSI eingestellt. Dennoch scheint die Shell eine andere Codierung zu benutzen, die Ausgabe ist immer noch kaputt. Was nun? :K

[jerch]

Probier mal cp850 oder cp1252.

Ich kenne PyScripter auch nicht und weiss nicht, wo die Ausgabe *** Remote Interpreter Reinitialized *** herkommt (eigener Konsolenemulator in PyScripter?), allerdings sieht die Ersetzung eines Umlauts in ein '?' nach einer der Windows-Codepages aus. In UTF8 sind Umlaute 2 Byte lang.

[Kebap]

Sorry, das "Remote Interpreter Reinitialized" stammt von Pyscripter und hat nichts weiter zu bedeuten, außer dass der Code soeben erneut ausgeführt wurde.

Hier nochmal das Ergebnis seit Umstellung auf UTF-8, hat sich nämlich doch geändert:

Code: Alles auswählen

*** Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32. ***
*** Remote Python engine  is active ***
>>> print "Umlaute: äöü ok"
Umlaute: äöü ok
>>> 
 

Ich habe auch mal cp850 oder cp1252 probiert durch "# -*- coding: cp1252 -*-", aber so lies sich die Datei nicht starten: SyntaxError: encoding problem: utf-8 (line 0)

[nomnom]

Sorry, das "Remote Interpreter Reinitialized" stammt von Pyscripter und hat nichts weiter zu bedeuten, außer dass der Code soeben erneut ausgeführt wurde.

Hier nochmal das Ergebnis seit Umstellung auf UTF-8, hat sich nämlich doch geändert:

Code: Alles auswählen

*** Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32. ***
*** Remote Python engine  is active ***
>>> print "Umlaute: äöü ok"
Umlaute: äöü ok
>>> 
 

Ich habe auch mal cp850 oder cp1252 probiert durch "# -*- coding: cp1252 -*-", aber so lies sich die Datei nicht starten: SyntaxError: encoding problem: utf-8 (line 0)

Dann ist deine Datei wohl immer noch UTF-8 … Wenn du ein anderes Encoding angibst, muss die Datei natürlich auch mit dem Encoding kodiert sein!

[Kebap]

Ich kann Code in dem Menü nur als Ansi, UTF-8 oder UTF16 speichern. Abgesehen davon habe ich zuletzt gar nichts gespeichert, sondern direkt in der eingebauten Shell gearbeitet. Ich sehe dort jetzt auch 2 Zeichen pro Umlaut, das passt zu dem, was jerch über UTF sagte. Wieso werden aber beide Byte angezeigt und nicht der Umlaut?

[deets]

Also wenn das, was du da gepostet hast, genau so in deiner Shell steht - dann ist die kaputt IMHO. Denn offensichtlich wird fuer die Eingabe von Zeichen UTF-8 verwand (dadurch dann die 2 Byte pro Umlaut), aber dann bei der Ausgabe ein 8Bit-Encoding ala latin1, cp1252 oder Co verwandt. Und da hast du ja keine Kontrolle drueber (ausser vielleicht in irgendwelchen Settings in Pyscripter, kenne das Ding nicht).

[jerch]

Was meldet denn sys.stdin.encoding zurück?

Wenn die eingebaute Shell nur 8Bit Encodings versteht, solltest Du auch Deine Dateien ensprechend anlegen oder musst halt jeden String, der aus dem Sourcecode direkt ausgegeben werden soll, umwandeln (z.B. 'äöü'.decode('utf-8').encode('latin1')) bzw. als Unicodestring anlegen und darauf hoffen, dass sys.stdout.encoding richtig gesetzt ist.

[jerch]

Das sieht tatsächlich nach einem Bug im PyScripter aus (oder falschen Settings für die Console, die die im Hintergrund starten, kA. ob Du das irgendwo einstellen kannst). IDEs haben eine Vorliebe fürs Patzen, wenns zur Console/Terminal kommt

Probier mal Folgendes:
Stell das Encoding zurück auf ANSI und teste mal, ob dann wenigstens die Shelleingabe korrekt ausgegeben wird. Dann stellst Du den Editor auch auf ANSI, wobei besser wäre, wenn Du anstelle von ANSI die Codepage direkt auswählen könntest. Wenn Du nur ANSI zur Verfügung hast, musst Du als nächstes "raten", welche Codepage Dein Windows als ANSI einsetzt. Bei mir unter Windows7 ist das cp850 an der Console. Für den Editor müsstest Du dann testen, mit welcher coding-Direktive die Strings korrekt umgesetzt werden. Wahrscheinlich ist es cp850 oder cp1252.

[snafu]

IDEs haben eine Vorliebe fürs Patzen, wenns zur Console/Terminal kommt

Wobei das imho heutzutage ein NoGo ist. Man sollte von jeder halbwegs modernen Anwendung erwarten können, dass sie mindestens mit UTF-8 umgehen kann. Das Ausführen von Code in irgendeiner Art von Shell gehört zu den grundsätzlichen Dingen, die eine IDE einfach fehlerfrei beherrschen muss.

Und sofern das Problem jetzt nicht zwischen Bildschirm und Tastatur sitzt, scheinen solcherlei Anpassungen, wie sie im nicht anglo-amerikanischen Raum nun mal vorkommen, bei PyScripter ja nicht gerade trivial zu sein.

Ich hoffe mal, ich hab die Messlatte jetzt nicht zu realitätsfern angelegt (Kodierungen sind ja selbst im noch überaus aktuellen 2er-Zweig von Python eine Sache für sich), aber dieser ganze Quatsch¹ macht einen doch einfach nur wahnsinnig...

___

¹ "Quatsch" natürlich nicht bezogen auf das Konzept an sich, sondern eher darauf, dass der Benutzer sich um sowas kümmern muss.

[BlackJack]

@snafu: Um diesen Quatsch muss sich der Benutzer immer selber kümmern. Das ist auch unabhängig von Python 2 vs. Python 3.

[Kebap]

Was meldet denn sys.stdin.encoding zurück?

Das teste ich natürlich gern, hat aber anscheinend nicht geklappt?

Code: Alles auswählen

*** Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32. ***
*** Remote Python engine  is active ***
>>> print sys.stdin.encoding 
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
NameError: name 'sys' is not defined
>>> import sys
>>> print sys.stdin.encoding
None
>>> print "Umlaute: äöü ok"
Umlaute: äöü ok
>>> 

Wenn ich den Code nicht direkt im Interpreter eingebe, sondern erst im Editor, dann speichere und ausführen lasse, dann passiert folgendes:
* Speichern als UTF-8: Wie oben (unabhängig ob coding: utf-8 angegeben ist)
* Speichern als ANSI: Fehlermeldung: Informationen werden verloren gehen, wenn in diesem Format gespeichert wird. Speichere ich dennoch und starte Code, erscheinen wieder die 3 Fragezeichen statt der 6 kryptischen Zeichen statt der 3 Umlaute.

Ich habe außerdem folgendes bemerkt:

Code: Alles auswählen

>>> print u"Umlaute: äöü ok"
Umlaute: äöü ok
>>> 

Aber ohne u vor den "" funktioniert das weiterhin nicht.

[jerch]

@snafu:
Meine Aussage ist trauriges Resultat verschiedener Tests mit den üblichen Verdächtigen in puncto Python, also Eclipse mit PyDev, Netbeans mit der experimentellen Pythonunterstützung, Eric, IDLE usw.

Zugegeben habe ich eine gewisse Konsolenaffinität, daher fällt mir die lausige Umsetzung vllt besonders auf, wirklich benutzbar ist keine der interaktiven Konsolen obiger IDEs, wenn man mehr will als einfaches Outputlogging. Natürlich bewegen sie sich im Rahmen der Spec, da Python klar sagt, das STDIN/STDOUT ein file-like object sein darf und nicht zwingend ein Terminal sein muss. Trotzdem erwarte ich von einer interaktiven Shell mehr, und nicht zuletzt sind viele Fehleranfragen hier im Forum darauf zurückzuführen, das IDLE mal wieder etwas ganz anders macht als die richtige Console. Zumal seit Pseudoterminals die Einbindung eines Terminals ziemlich einfach ist (und man sich auch unter Windows über die Win-API eine Console holen kann). Problem ist halt der Emulator, den will keiner schreiben...

[snafu]

@snafu: Um diesen Quatsch muss sich der Benutzer immer selber kümmern. Das ist auch unabhängig von Python 2 vs. Python 3.

Dem Benutzer kann aber eine sinnvolle Voreinstellung an die Hand gegeben werden (also UTF-8 statt ASCII), oder liege ich damit jetzt völlig falsch?

[jerch]

Dem Benutzer kann aber eine sinnvolle Voreinstellung an die Hand gegeben werden (also UTF-8 statt ASCII), oder liege ich damit jetzt völlig falsch?

Microsoft hat UTF-8 erst sehr spät als Standard anerkannt (wohl eher zähneknischend), ich glaube es wird erst seit SP3 für XP oder gar Vista als Option angeboten. Bei UTF-16 vs UFT-32 geht Windows auch einen anderen Weg, d.h. nichtmal die interne Unicoderepräsentation in Python ist gleich zu Linuxdistributionen. Das Encoding-Gewurschtel ist schon ziemlich nervig.
Jeder, der da nun ein Tool, IDE oder was auch immer schreiben will, welches plattformübergreifend funktionieren soll, muss zwangsläufig diese Eigenheiten beachten.

@Kebap:
Hmm, das würde ich jetzt doch als Bug von PyScripter ansehen, da scheint weder Input- noch Outputencoding der Shell gesetzt zu sein.
Stell den Editor bitte mal auf ANSI um und erstell die Datei neu, d.h. schreib die Umlaute von der Tastatur aus. Als coding-Directive würde ich cp1252 und cp850 probieren. Wie geht er mit Unicodestrings aus der Datei in der Shell um?

[Kebap]

Hi jerch,

wenn ich folgende Datei als ANSI speichere:

Code: Alles auswählen

# -*- coding: cp1252 -*-
print "äöü"

erhalte ich diesen Output:

Code: Alles auswählen

*** Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32. ***
*** Remote Python engine  is active ***
>>> 
*** Remote Interpreter Reinitialized  ***
>>> 
äöü
>>> print "äöü"
äöü
>>> 

Anscheinend funktioniert also schonmal irgendwas, wenn auch kein UTF-8..

[jerch]

Ah das ist gut. Kannst Du die Shelleingabe auch umstellen? Dann sollte der Bytesalat am Ende auch verschwinden.

[snafu]

Dem Benutzer kann aber eine sinnvolle Voreinstellung an die Hand gegeben werden (also UTF-8 statt ASCII), oder liege ich damit jetzt völlig falsch?

Microsoft hat UTF-8 erst sehr spät als Standard anerkannt (wohl eher zähneknischend), ich glaube es wird erst seit SP3 für XP oder gar Vista als Option angeboten. Bei UTF-16 vs UFT-32 geht Windows auch einen anderen Weg, d.h. nichtmal die interne Unicoderepräsentation in Python ist gleich zu Linuxdistributionen. Das Encoding-Gewurschtel ist schon ziemlich nervig.
Jeder, der da nun ein Tool, IDE oder was auch immer schreiben will, welches plattformübergreifend funktionieren soll, muss zwangsläufig diese Eigenheiten beachten.

Code: Alles auswählen

encoding = 'cp1252' if on_windows else 'utf-8'

...eine simple Zeile für eine Voreinstellung, die unter Umständen viele Probleme lösen kann.

Naja, will mich jetzt nicht dran aufhängen...