Das deutsche Python-Forum

Hallo Forum,

ich bin auf Python gestossen, und würde gerne diese Programmiersprache erlernen.
Nun da mir Ansätze der Reihenfolge eines Programms fehlen, benötige ich einen Leitfaden zum Programmieren....

Wie zum Beispiel:

1: EINGABE EINER ZAHL
2: WENN KEINE ZAHL DAVOR EINGEGEBEN WURDE, DANN DIE ENDSCHEIDUNG DER NÄCHSTEN ZAHL
3: WENN ZWEITE EINGEGEBENE ZAHL "HÖHER IST", DANN BERECHNE - 80%
4: WENN ZWEITE EINGEGEBENE ZAHL "KLEINER IST" DANN BERECHNE + 80 %
5: AUSGABE ERSTE ZAHL
6: AUSGABE ERGEBNIS DER ZWEITEN ZAHL
7: MIT RETURN ALLES LÖSCHEN, UND WIEDER ZUM ANFANG

Hier habe ich jetzt ein kleines Beispiel Aufgeführt.
Ich benötige jetzt einen Leitfaden, um zu entscheiden und zu lernen anhand eines kleines Beispiels, wie die Reihenfolge abläuft.

Natürlich ist mir Bewusst, dass erst Eingabe, dann Berechnung, dann Ausgabe Erfolgt....mir geht es aber dann wann Schleifen eingefügt werden, und wo wenn es um endscheidungen geht.

Ich hoffe ihr könnt mir HELFEN um die Syntax besser zu verstehen.

Besten Dank

Hallo User2014,
ich verstehe Deine Frage nicht. Die von Dir gezeigten Befehle lassen sich fast wörtlich nach Python übersetzen.
Zum Beispiel »WENN ZWEITE EINGEGEBENE ZAHL "KLEINER IST" DANN BERECHNE + 80 %« wird zu Schleifen fassen dann die Befehle ein, die wiederholt werden sollen.

Wenn du die Python Basics kennen würdest, würdest du derartige Fragen nicht stellen.
Deswegen rate ich dir eines von tausenden online Tutorials zu lesen.

Wenn du aus Beispielen besser lernst.

Alternative:

Da sieht man mal wieder, dass mit Python 2 alles einfacher war.
Die mittlere Zeile:

Sirius3 hat geschrieben:Da sieht man mal wieder, dass mit Python 2 alles einfacher war.

„alles“? "..." als Hort für Byte-Rohdaten und u"..." als Hort für normale Strings ist einfacher? Und noch dazu immer im Kopf der Datei das Encoding angeben zu müssen?

Man könnte es natürlich selbst implementieren: Oder als:

@EyDu: zu Deiner Variante 2: -1.8 ≠ 0.2
@Hellstorm:

@Hellstorm: Bei Dateien muss man immer noch die Kodierung angeben denn das ”geratene” muss nicht das gewollte sein, und an dem u'' wirst Du das doch nicht wirklich festmachen? Zumal es dagegen einen `__future__`-Import gibt. Um Bytes vs. Zeichenketten muss man sich nach wie vor die gleichen Gedanken machen wenn man keinen kaputten Code schreiben will, nur das Python 3 es einfacher macht kaputten Code zu schreiben weil der einem nicht wie in Python 2 *sofort* auf die Füsse fällt wenn etwas ausserhalb von ASCII vorkommt. Und dann die neu hinzugekommenen Probleme wo Python 3 für einen entscheidet ob und wie etwas dekodiert werden soll, wie zum Beispiel im `email`-Paket wenn da jemand rohe Bytes in einen MIME-Teil steckt, Python 3 aber meint das unbedingt dekodieren zu müssen.

BlackJack hat geschrieben:@Hellstorm: Bei Dateien muss man immer noch die Kodierung angeben denn das ”geratene” muss nicht das gewollte sein,

Die Standardkodierung von Python-3-Dateien ist aber UTF-8, also muss man es doch eben nicht. Da wird ja auch nichts geraten, bei Python 3 gilt als Standard UTF-8 und gut.

BlackJack hat geschrieben:und an dem u'' wirst Du das doch nicht wirklich festmachen? Zumal es dagegen einen `__future__`-Import gibt.

Klar mach ich das (unter anderem) an dem u" fest. Das ist doch absolut unlogisch. Gründe:

1. Was soll an einem „ä“ groß anders sein als an einem „a“, außer dass ein ä nicht in ASCII vorhanden ist? Das ist kein Grund, ein „ä“ irgendwie als etwas besonderes zu sehen.
2. Viele Leute kümmern sich nicht um die Kodierung (siehe unten) und nutzen einfach "..." . Insbesondere als Anfänger. Mit der Folge, dass diese Programme Zeichenketten nicht anständig verarbeiten können.
3. Schon allein vom Schreibaufwand her ist es merkwürdig, immer u"..." schrieben zu müssen. Das verleitet auch dazu, das u mal zu vergessen.
4. Die Trennung von „Text-Strings“ und „Rohdatenfolgen“ (nenne ich jetzt mal so) ist bei Python 3 doch viel logischer: Alles was irgendwie ein Endprodukt ist oder vom Menschen lesbar sein soll kommt in "...", etwas was das nicht ist (Audiodateien oder die zugrundeliegenden Bytes der Strings) kommen in ein b"..." (kann man übrigens imho ganz gut bei PySerial erkennen, wo über den Com-Port immer b"..."-Strings kommen, die dann erst mit .decode umgewandelt werden müssen). Ich würde mal davon ausgehen, dass man normalerweise eher doch mit normalen „Text-Strings“ arbeitet, weswegen es logischer ist, diese als Standard zu kennzeichnen.
Wobei ich auch dort noch Fehlerquellen sehe, indem das lateinische Grundalphabet auch in b"..." weiterhin mit Buchstaben gekennzeichnet wird. Logischer wäre es im Grunde gewesen, dort wie in einem Hex-Editor immer nur die Bytewerte anzugeben.

BlackJack hat geschrieben: Um Bytes vs. Zeichenketten muss man sich nach wie vor die gleichen Gedanken machen wenn man keinen kaputten Code schreiben will, nur das Python 3 es einfacher macht kaputten Code zu schreiben weil der einem nicht wie in Python 2 *sofort* auf die Füsse fällt wenn etwas ausserhalb von ASCII vorkommt.

Ich sehe es eher andersherum: Bei Python 2 gibt es viele Leute, die sich keine Gedanken um Kodierungen zu machen („Englisch läuft ja“), so dass es einem eben nicht sofort auf die Füße fällt.

Bei Python 3 läuft es zuerst einmal relativ gut out of the box. Wobei ich ehrlich gesagt noch nie die Probleme gesehen habe, die du meinst. Bei Python 3 läuft doch alles super, wenn man UTF-8 annimmt. Wenn nicht, dann setzt man eben noch eine Umwandlung davor.

BlackJack hat geschrieben: Und dann die neu hinzugekommenen Probleme wo Python 3 für einen entscheidet ob und wie etwas dekodiert werden soll, wie zum Beispiel im `email`-Paket wenn da jemand rohe Bytes in einen MIME-Teil steckt, Python 3 aber meint das unbedingt dekodieren zu müssen.

Da kenn ich mich nicht genau aus, aber in der Dokumentation steht z.B. folgendes:

New functions message_from_bytes() and message_from_binary_file(), and new classes BytesFeedParser and BytesParser allow binary message data to be parsed into model objects.

Ist das nicht das, was du meinst?

@Hellstorm: Ich dachte Du meinst mit Dateien die man mit Python bearbeitet, nicht Quelltexte selbst. Das ``# coding: utf-8`` ist bei mir im Template, das steht da schon wenn ich eine neue Python-Datei erstelle. Macht also keine Arbeit, setzt aber einen vernünftigen Editor voraus.

Bei Python 3 läuft das gut wenn man UTF-8 annimmt? Das tut doch aber keiner, insbesondere nicht Python selber. Das wäre ja schön! Nein, Python nimmt die „Standardkodierung des Systems” an, was immer das bedeuten mag. Ein Programm kann dann die von ihm selbst geschriebenen Textdaten nicht mehr lesen wenn man Programm und Dateien auf ein anderes System überträgt wo eine andere Kodierung „geraten” wird, oder wenn man die Systemeinstellungen ändert. Das geht alles nur so lange gut wie man immer nur schön in seiner eigenen kleinen Welt bleibt. Genau das nervt mich ja, die Leute merken vielleicht erst Jahre später das ihr Programm gar nicht ordentlich mit Kodierungen umgehen kann, wenn schon unzählige Datendateien produziert worden sind. Bei Python 2 wäre das sofort beim ersten Nicht-ASCII-Zeichen aufgefallen. Und das Grundsätzliche Problem gibt es auch weiterhin, nur ist es von ASCII auf einen anderen Zeichensatz verschoben. So wie man in Python 2 mit einem Zeichen ausserhalb von ASCII auf die Nase fällt, genau so wird man unter einem deutschen Windows entweder bei CP850 oder CP1251 auf die Nase fallen, je nach dem ob man das Programm als Windows- oder als DOS-Programm laufen lässt. Subjektiv haben die Leute aber das Gefühl das mit Unicode sei jetzt einfacher geworden. Falsche Sicherheit… Ich kann natürlich jetzt sagen ich programmiere unter Linux, da ist eigentlich überall UTF-8 eingestellt, aber die Haltung unterscheidet sich ja nicht wirklich von dem „Ich verwende nur ASCII der Rest ist mir Wurst” was Du für Python 2 angemerkt hast. Auch für Python 3 gilt: Wenn man an den „Grenzen” nicht explizit (de)kodiert, kann das Skript nicht wirklich vernünftig mit Zeichenketten umgehen.

Die Parser-Geschichten meine ich nicht, beziehungsweise sind die ja auch betroffen. Die versuchen grundsätzlich nach Text zu dekodieren, auch wenn rohe Binärdaten enthalten sind, also zum Beispiel eine JPG-Datei. Das geht solange gut wie das zum Beispiel Base64-kodiert ist — da bekommt man dann Unicode-Zeichenketten die die Base64-kodierten Binärdaten enthalten. Über den Sinn davon kann man auch streiten. Aber wenn die Daten wirklich roh als Bytes in einem Part stecken, dann fällt das Modul auf die Nase. Da gab es neulich hier ein Thema zu.

Übrigens auch noch etwas was mich total nervt: `sys.argv` wird dekodiert. Da möchte ich jetzt mal gerne wissen wie ich beispielsweise unter Linux einen Dateinamen als Argument übergeben soll dessen Kodierung nicht der „Systemkodierung” entspricht. Oder auch andere Argumente. Ich habe da zum Beispiel ein Skript da wird eine ”Zeichenkette” erwartet in einer Kodierung die völlig an jedem Standard vorbei geht. Die Bytes müssen 1:1 an eine externe Bibliothek übergeben werden. `argv` in C sind Bytes, Python soll das gefälligst nicht ungefragt dekodieren und mir dann auch noch *keine* Möglichkeit der Intervention lassen.