Das deutsche Python-Forum

Ist nicht gerade Pythonspezifisch, eher Editorspezifisch. Bei IDLE muss man bspw. nur einen Block markieren und auf Tabulator drücken, schon wird der Block eingerückt.

(Für deinen Fall brauchst du übrigens eher eine while schleife, in solchem Stil:

Code: Alles auswählen

while True:
    <operationen>
    foo = raw_input("Weiterrechnen[J/n]? ")
    if foo.lower() == "n":
        break

Oder hab ich dich falsch verstanden?)

mathi hat geschrieben:muß ich jetzt wirklich die 30 Zeilen die ich schon geschrieben habe händisch einrücken um die blöcke zu definieren [...] oder gibt es einen automatismus?

Das haengt von deinem Editor ab. In Emacs kann man einen ausgewaehlten Bereich nach links/rechts verschieben: py-shift-region-right bzw. C-c > (und entsprechend fuer die andere Richtung).

Ganz automatisch kann so etwas natuerlich nicht gehen, da Bloecke ja ein wichtiges Syntax-Element darstellen.

Und ich kann mir diesen Link nicht verkneifen: http://if-schleife.de/

Das scheint jemandem sehr wichtig zu sein.

@mathi: Das sieht nach einer "Übersetzung" eines BASIC-Programms nach Python aus. Wenn Du damit fertig bist, solltest Du Python etwas intensiver lernen und es dann noch einmal überarbeiten. Was bei einer 1:1 Umsetzung heraus kommt dürfte nämlich kein schöner Python-Code werden.

vielen Dank für die Hinweise, Ratschläge.

Ich wollte halt damit anfangen und mich so langsam in Python einarbeiten. Icch freue mich aber, dass die kleinen Anfangsschwiegigkeiten (bin kein Informatiker sondern Bau-Ing.) trotzdem Beantwortung finden.

@BlackJack:

die Site ist interessant

Rebecca hat geschrieben:
mathi hat geschrieben:muß ich jetzt wirklich die 30 Zeilen die ich schon geschrieben habe händisch einrücken um die blöcke zu definieren [...] oder gibt es einen automatismus?
Das haengt von deinem Editor ab. In Emacs kann man einen ausgewaehlten Bereich nach links/rechts verschieben: py-shift-region-right bzw. C-c > (und entsprechend fuer die andere Richtung).

Analog dazu in nutze ich in Vim die Blockauswahl mit Shirft + V und dann '>', '<' zum ein und ausrücken oder gar '2>' und '2<' wenn es mehrere Einrückungsebenen sein sollen.

ich nutze IDLE und bin wirklich zufrieden damit

wieder ein Problem:

ich nutze
# -*- coding: cp1252 -*-

aber wenn ich mit pyinstaller ( -F -c ) eine .exe erzeuge wird ("mm²") (das Quadrat) nicht dargestellt. Im IDLE ist es richtig.

Was mache ich falsch?

Wie gibst Du das '²' ein und wo wird es nicht richtig dargestellt? Die Kodierungsangabe bewirkt das korrekte Dekodieren von Unicode-Zeichenketten-Literalen im Quelltext ─ sonst nichts.

Edit: Und man muss natürlich auch wirklich in der Kodierung speichern, die man im Kommentar angegeben hat.

ich gebe mit ALTGr+2 ein, und sehe in der Win-Console (habe die .exe mit der option -c erstellt) statt dem ² nur ein graues Feld ( unter Linux hieße das für mich z.B. UTF-8 versuchen, klappt hier aber nicht, denn dann siehts noch schlimmer aus).

-> ich denke, ich spreche im richtigen Code, da beim ausführen des Programms in IDLE ja alles richtig ist - oder?

meine Vermutung ist, das die Console von Windows das nicht packt?? -> falsch habs grad getestet geht, muß also an der "Übersetzung" des pyinstallers liegen.

Edit: im Handbuch von pyinstaller finde ich nichts

Sorry, bei Eingabe meinte ich was da wirklich in Deinem Code steht, also steht da eine Unicode-Zeichenkette, wo im Quelltext der passende Bytewert für das ²-Zeichen steht, oder ist es eine normale Byte-Zeichenkette? Bei letzterem klappt die Ausgabe natürlich nur wenn das "Ausgabemedium" die gleiche Kodierung versteht, in der das Zeichen im Quelltext kodiert ist, oder der Bytewert für das Zeichen in beiden Kodierungen zufällig gleich ist.

Der Kommentar sagt nichts darüber aus ob er zur tatsächlichen Kodierung des Quelltextes passt. Und das ein in IDLE eingegebener Text in Byte-Zeichenketten in IDLE wieder ausgegeben wird, wie er eingegeben wurde, hat ebenfalls nichts zu bedeuten. Innerhalb von IDLE wird ja immer die selbe Kodierung verwendet.

Kodierungen sind eine "lustige" Sache und letztendlich läuft's darauf hinaus, dass man bei robusten Programmen, die wirklich mit Zeichen umgehen sollen a) intern durchgehend mit Unicode arbeiten muss; b) an den "Ein-" und "Ausgängen" dafür sorgen muss, dass entsprechend de- und enkodiert wird; und c) eine Option für die Ein- und Ausgabe-Kodierungen vorsehen muss, weil man die nicht in allen Fällen automatisch ermitteln kann.

Zur Windowskonsole: Das Ding heisst ja manchmal auch DOS-Eingabeaufforderung und verwendet dementsprechend normalerweise auch eine andere Kodierung als "Windows".

das lustige ist: ich wollte ein programm schreiben (.py) dass ich in Linux und Windows gleichermaßen anwenden kann, ABER:

UTF-8 zeigt unter Linux ein ü
unter Windows aber kryptische Zeichen ->(Edit: Ã¼) =8895-1?
, sollte da nicht bei gleicher kodierung das gleiche rauskommen?

Nein natürlich nicht. Wenn bei gleicher Kodierung überall das gleiche dargestellt würde, könnte man ja *eine* Kodierung nehmen und die anderen alle vergessen. Das wäre schön.

In UTF-8 wird ein ä mit zwei Bytes kodiert: '\xc3\xa4', bei iso-8859-1 als ein Byte: '\xe4'. Wenn man die beiden ersten Bytes irgendwo ausgiebt wo iso-8859-1 erwartet wird, werden die beiden Zeichen Ã¼ angezeigt.

Wenn Du ein Programm schreiben willst das "überall" läuft, musst Du wie gesagt intern mit Unicode arbeiten und für den Notfall den Benutzer die Kodierung angeben lassen in welcher Kodierung das ausgegeben werden soll. Zum Beispiel sowohl unter Windows als auch unter Linux beim Umleiten der Ausgabe in eine Datei. Dateien bestehen aus Bytes, die haben keine Kodierung, also muss man explizit sagen welche verwendet werden soll wenn man Unicode-Text hineinschreiben will.

Edit:

http://www.python-forum.de/topic-5095.html

hab ich grad gefunden, hätte mir dann wohl die Frage ersparen können.

Das deutsche Python-Forum

sprünge?