ubuntuusers.de

Hallo,

ich beschäftige mich seit einer Woche mit Python3 und bin hellauf begeistert. Und schon tritt das erste Problem auf:

#!/usr/bin/python3


while True:
	s = input('Enter something : ')
	if s == 'q':
#	    print('abgebrochen')
		break
	if len(s) < 3:
#	    print('es geht geht weiter')
		continue
	print('Input is of sufficient length')

das funktioniert auch.

Entferne ich das Kommentar, sodass vor "break" oder "continue" eine weitere Anweisung steht:

#!/usr/bin/python3


while True:
	s = input('Enter something : ')
	if s == 'q':
	    print('abgebrochen')
	    break
        if len(s) < 3:
	    print('es geht geht weiter')
            continue
	print('Input is of sufficient length')

kommt es zu einer Fehlermeldung.

  File "/home/hans/.bin/pt", line 12
    continue
           ^
TabError: inconsistent use of tabs and spaces in indentation

Es scheint mir völlig unsinnig, dass vor "break" oder "continue" keine weitere Anweisung stehen darf.

mfG drhawo

Hallo,

bitte benutze doch für Quellcode die entsprechenden Tags hier im Forum; man kann Python-Code auch wunderschön darstellen lassen 😉

Zum Fehler: Der Interpreter schreibt Dir doch deutlich, was ihm missfällt: Du vermischst offenbar Tabulatoren und Spaces bei den Einrückungen.

Generell kannst Du Dir merken: Benutze *niemals* Tabs beim Programmieren. Einrückungen sollten immer duch Leerzeichen entstehen.

Bei jede4m guten Editor kannst Du einstellen, dass dieser anstelle eines Tabs eine beliebige Anzahl Leerzeichen drucken soll - kein Mensch mag 12 Mal auf die Leerzeile tippen 😉

In Python solltest Du Dich an PEP8 halten, welches *vier* Spaces pro Einrückungsebene vorsieht.

Also mein Tipp: Stelle Deinen Editor entsprechend ein, markiere den gemsamten Code, drücke einmal die Tab-Taste und anschließend noch einmal zusammen mit Shift. Damit solltest Du alles wieder gesäubert haben.

Funzt das nicht, dann entferne eben alle Einrückungen und nimm dieser erneut vor.

So läuft es bei mir ohne Probleme:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/usr/bin/env python3

while True:
    s = input('Enter something : ')
    if s == 'q':
        print('abgebrochen')
        break
    if len(s) < 3:
        print('es geht geht weiter')
        continue
    print('Input is of sufficient length')

Eine kurze Anmerkung noch: Ich weiß nicht, ob Python Deine erste Programmiersprache ist, aber unabhängig davon ist s ein schlechter Name! Was bedeutet denn s? Dieser Code ist zwar so klein, dass man die noch überblicken kann, aber das A und O beim Programmieren ist das Finden von guten Namen. Wie wäre es mit choice? Oder gar user_choice? Damit erkennt man in späteren Zeilen doch sofort, was sich hinter dem Namen verbirgt!

Hallo Lysander,

gleich einmal ein Dankeschön, es hat wunderbar geklappt. Hätte mich wahrscheinlich "tot gesucht", da ich nie daran gedacht hätte, dass ein TAB mit 4 Stellen nicht zuverlässig 4 Leerzeichen sind. Die Fehlerausgabe konnte ich mir deshalb nicht erklären, aber "das Sytem hat immer recht".

"Tags zur Darstellung im Hervorhebungsmodus" war mir nicht bekannt, ich werde nachlesen und es dann nächstes Mal hoffentlich richtig machen.

Die kurzen Bezeichner sind sicher nicht üblich, ich verwende sie jedoch gerne beim Testen und in kurzen Funktionen mit ausreichender Übersicht, dokumentiere dann aber auch ausführlich, sodass ich auch später noch weiß was sie bedeuten. Die Anweisungzeilen bleiben deutlich kürzer, Schreibfehler kommen seltener vor. Das gilt natürlich nur für lokale Variabel in kurzen Code-Abschnitten.

mfG und ein nochmaliges Danke, drhawo.

Die Fehlermeldung kommt wegen der unterschiedlichen Einrückung. Sie kommt beim ersten Beispiel *nicht*, weil mit einer Raute beginnende Zeilen als Kommentar aufgefasst werden und daher komplett ignoriert werden. In dem Fall (also wenn man die Kommentarzeilen quasi rauslöschen würde, aber den Rest exakt so stehen lässt), ist die Einrückung nämlich wieder konsistent.

drhawo schrieb:

Die kurzen Bezeichner sind sicher nicht üblich, ich verwende sie jedoch gerne beim Testen und in kurzen Funktionen mit ausreichender Übersicht, dokumentiere dann aber auch ausführlich, sodass ich auch später noch weiß was sie bedeuten. Die Anweisungzeilen bleiben deutlich kürzer, Schreibfehler kommen seltener vor. Das gilt natürlich nur für lokale Variabel in kurzen Code-Abschnitten.

Ich finde so kurze Namen auch oft ausreichend, wenn die Variable nur innerhalb weniger Zeilen benutzt wird und es nicht zu viele gleichzeitig sind.

drhawo schrieb:

Die kurzen Bezeichner sind sicher nicht üblich, ich verwende sie jedoch gerne beim Testen und in kurzen Funktionen mit ausreichender Übersicht, dokumentiere dann aber auch ausführlich, sodass ich auch später noch weiß was sie bedeuten. Die Anweisungzeilen bleiben deutlich kürzer, Schreibfehler kommen seltener vor. Das gilt natürlich nur für lokale Variabel in kurzen Code-Abschnitten.

Deine Einstellung solltest Du noch einmal überdenken. Wenn Du nämlich die Bedeutung eines Namens erst noch *dokumentieren* musst, so merkst Du ja selber, dass die Aussagekraft ziemlich gering ist. Du baust damit ein künstliches Mapping in Deinen Code ein, das zusätzliche Komplexität erschafft. Stell Dir Mal das Spiel UNO gegen MauMau vor - was lässt sich wohl intuitiver spielen? Genau, das Spiel, welches für eine Aktion eine ausdrucksstarke Iconografie besitzt... Onkel Bob hat für Deine Haltung sogar einen Namen, den habe ich leider im Moment nicht zur Hand.

Das Platzargument erübrigt sich damit ebenfalls; denn zusätzliche Kommentare machen den Code auch nicht kürzer.

Die Länge eines Namens ist heutzutage auch kein Problem mehr; Speicherplatz für Quellcode ist zur Genüge vorhanden und dank guter Editoren oder IDEs gibt es auch Autocompletion usw.

Ein Name sollte auch stets kurz gewählt sein; allerdings niemals kürzer als notwendig! Wenn ich die Bedeutung in zwei Varianten gleich gut ausdrücken kann, so wähle ich natürlich die kürzere.

In einem Punkt hast Du ggf. recht: es gibt teilweise gebräuchliche Konventionen; so ist eben das i in Schleifen für einen ganzzahligen Index ok. Dazu kommen Fachtermini der jeweiligen Domäne. Wenn ich Code für eine PQ-Formel schreibe, so kann ich natürlich p und q benutzen; selbiges gilt für viele naturwissenschaftliche Bereiche.

@diesch Natürlich ist es Abwägungssache, wie genau man es damit nimmt. Ich habe jedoch die Erfahrung gemacht, dass das Suchen von ausdrucksstarken Namen auch Trainingssache ist. Und wenn ich das nicht Tag täglich *auch* im Kleinen übe, so werde ich micht darin nicht verbessern und auch nicht mein Niveau halten.

Wenn ich darin nämlich gut bin, so flutscht mit ein passender Name für obigen Code einfach so heraus - und dann empfinde ich als Coder das auch nicht mehr als umständlich oder gar unnötig für so kleinen Code. Ich tue das dann intuitiv.

Und sind wir mal ehrlich: Wieso hat der OP oben das s gewählt? Imho steht es für einen beliebigen String. Da ihm kein besserer Name eingefallen ist, hat er sich überlegt, welcher Datentyp von input zurück kommt und darauf basierend den Namen gewählt. Oder sollte ich hier falsch liegen? Eine bessere Erklärung fällt mir nicht ein - das Ergebnis ist so oder so schlecht, *mit* meiner Erklärung allenfalls noch einen Tucken schlechter, da man so eine nicht wünschenswerte Perversion der ungarischen Notation mit in seinen Code eingebaut hat 😉 Denn Typen sollten *nie* *nie* *niemals* *nie* in einem Namen codiert sein!

Willkommen drhawo im Club der Pythonbegeisterten! ☺ Ich kann aus eigener etwa einjähriger Erfahrung nur sagen, es wird mit der Zeit immer besser. Diese Sprache ist einfach ein Traum 😎

LG barrios