Dictionary

[Bloos]

Liebe Python Community,

habe vor einigen Jahren in der Schule mit C++ programmiert, bin nun auf Python gestoßen und es macht mir riesen spaß Hab aba noch nicht den durchblick und bräuchte bisschen hilfe

ich habe vor eine art wörterbuch zu programmieren, was ich zu erst fülle und es mich dann nach den vokabeln abfragt.

das problem vor was ich stehe ist das abspeichern und wieder abrufen von daten, damit die vokabeln beim nächsten start nicht neu eingegeben werden müssen(obwohl das wohl auch eine art des vokabeln lernens wär )

habe schon einige hilfen durchgelesen aber nicht den passenden anhaltspunkt gefunden.

Also ich speicher meine vokabeln in eine Liste ab, aber wie speichere ich die in ein txt (o.ä.) ab und wie kann ich es mit dem selben bezeichner wieder abruffen?

Hier eine beta version des Eingabebereiches.

Code: Alles auswählen

 def eingabe():
    os.system("cls") 
    deuvok = ['Deutsch']
    engvok = ['Englisch']
    deuvok.append(raw_input("\n\n\tGib die Deutsche Vokabel ein: "))
    engvok.append(raw_input("\n\tGib die Englische Vokabel ein: "))
    x = len(engvok) - 1
    print "\n\t", deuvok[x], "=", engvok[x]
    vokein = int(raw_input('\n\n\tGib 1 ein, um eine weitere Vokabel einzugeben.'))
    if vokein == 1:
        eingabe()

Danke schon mal an alle die den Thread durchgelesen haben

[cofi]

Hallo Bloos, willkommen im Forum!

1. Solltest du deine Datenstruktur aendern: Benutze (zwei) Dictionaries statt (zwei) Listen.

2. Um deine Daten zu speichern hast du mehrere Moeglichkeiten:
a) [mod]pickle[/mod] zum direkten Speichern deiner Dictionaries.
b) Datenbank ([mod]sqlite3[/mod], ...)
c) Du "simulierst" eine Datenbank mit Textdateien, da waere [mod]csv[/mod] eine Moeglichkeit.
Im Wiki ist auch noch ein Artikel, den find ich aber gerade nicht.

Edit: `os.system` solltest du vermeiden [mod]subprocess[/mod] ist die bessere Alternative.
Deine Funktion hat auch ein grosses Problem: Sie macht zuviel. Sie kuemmert sicht nicht nur um die "eingabe" (wie der Name sagt), sondern erstellt auch neue Listen (ohne sie herauszugeben) und hat auch eine Steuer-/Menuefunktion. Den rekursiven Aufruf sollte man auch vermeiden

[fabi1511]

tja, dieser Liste gibt es eigentlich nichts hinzuzufügen, hier noch ein paar allgemeine verbesserungsvorschläge für dein skript:

die rekursion würde ich mit

Code: Alles auswählen

while True:
    ...
    if vokein == 1:
        break

auflösen

und so wie du das gelöst hast, könntest du auch gleich

Code: Alles auswählen

input()

statt

Code: Alles auswählen

int(raw_input())

benutzen, wenn du kein Exception-Handling benutzt macht das für mich keinen Sinn, sondern stellt nur eine weitere Fehlerquelle dar.

Anstatt

Code: Alles auswählen

x = len(engvok) - 1
print "\n\t", deuvok[x], "=", engvok[x]

solltest du besser

Code: Alles auswählen

print  "\n\t",deuvok[-1],"=",envok[-1]

benutzen

[bords0]

und so wie du das gelöst hast, könntest du auch gleich

Code: Alles auswählen

input()

statt

Code: Alles auswählen

int(raw_input())

benutzen, wenn du kein Exception-Handling benutzt macht das für mich keinen Sinn, sondern stellt nur eine weitere Fehlerquelle dar.

input sollte man gar nicht verwenden! Vielleicht meinst du raw_input, und dann mit "1" vergleichen statt mit 1? Das fände ich auch sinnvoll.

[cofi]

die rekursion würde ich mit ..snip..
auflösen

Nein, die Rekursion hat darin gar nichts zu suchen. Aber generell hast du recht, aber, dass das in eine andere Funktion gehoert, darf man nicht unter den Tisch fallen lassen

wenn du kein Exception-Handling benutzt macht das für mich keinen Sinn, sondern stellt nur eine weitere Fehlerquelle dar.

Inwiefern eine Fehlerquelle? Da man keine Zahl benoetigt, kann man auch gleich den Rueckgabewert von `raw_input` nutzen.

Anstatt

Code: Alles auswählen

x = len(engvok) - 1
print "\n\t", deuvok[x], "=", engvok[x]

solltest du besser

Code: Alles auswählen

print  "\n\t",deuvok[-1],"=",envok[-1]

benutzen

Nein das macht das nicht wirklich besser. Lieber so:

Code: Alles auswählen

german = raw_input("Gib die Deutsche Vokabel ein: ")
english = raw_input("Gib die Englische Vokabel ein: ")
deuvok.append(german)
engvok.append(english)
print "%s = %s" % (german, english)

[BlackJack]

@fabi1511: ``int(raw_input())`` kann man nicht einfach durch `input()` ersetzen. Bei ersterem kann zwar eine Ausnahme kommen, wenn keine Zeichenkette einegeben wurde, die man in eine ganze Zahl umwandeln kann, aber man kann dort nicht beliebige Python-Ausdrücke eingeben und ausfühten, wie das bei `input()` möglich ist. Das ist schon ein deutlicher Unterschied.

Zur Datenstruktur würde ich mal sagen *eine* zu nehmen und nicht zwei parallele, die eigentlich zusammengehören. Also Dictionary oder Liste mit Tupeln vielleicht.

[fabi1511]

nochmal zu der input sache, da hab ich mich wohl unklar ausgedrückt:

int(raw_input()) stellt für mich insofern eine fehlerquelle mehr dar, da jeder string, der nicht in eine int umgewandelt werden kann zu einem fehler führt, gibt man bei ´´input´´ einen etwas wie "[1,2,3,4]" (ohne anführungszeichen ein), läuft das programm weiter, bei ``int(raw_input())`` stürtzt es jedoch ab...

ganz sauber macht man das natürlich mit try...except, ich wollte nur sagen, dass der ansatz garnicht schlecht war, aber in dieser form keinen wirklichen vorteil zu ``input()`` ,was natürlich die schlechteste lösung ist bringt

und ich weiß auch, dass ``int(raw_input())`` kein Äquivalent zu ``input()`` ist, aber in diesem fall, wenn man auf 1 oder nicht 1 testen will schon...

[BlackJack]

@fabi1511: Auch in *dem* Fall nicht, denn man kann immerhin nicht nahezu beliebigen Quelltext ausführen. Das ist eine Sicherheitslücke, die man bei `raw_input()` nicht hat.

[cofi]

int(raw_input()) stellt für mich insofern eine fehlerquelle mehr dar, da jeder string, der nicht in eine int umgewandelt werden kann zu einem fehler führt, gibt man bei ´´input´´ einen etwas wie "[1,2,3,4]" (ohne anführungszeichen ein), läuft das programm weiter, bei ``int(raw_input())`` stürtzt es jedoch ab...

Fuer mich ist das Gegenteil der Fall: Ich will eine Zahl, bekomme bei `input` aber beliebiges zurueck. Hier fuehrt spaetestens der naechste Schritt zu einem Fehler oder zu unerwartetem Verhalten. Das Problem kann man nur loesen, indem man den Fehler behandelt, wozu man bei `input` aber gar keine Moeglichkeit hat.

[numerix]

Es lebe Python 3!

[fabi1511]

Es lebe Python 3!

find ich nicht... vieles von dem neu eingeführten verwirrt nur, aber das ist ein ganz andres thema

[numerix]

Es lebe Python 3!

find ich nicht... vieles von dem neu eingeführten verwirrt nur, aber das ist ein ganz andres thema

1. Dieser Ausruf bezog sich konkret auf die raw_input()/input()-Geschichte. Das ist schon soooo oft hier im Forum durchgekaut worden und ich freue mich auf die Zeit, wo das nicht mehr nötig ist, weil (falls?) sich Python 3 durchgesetzt hat.

2. Es lässt sich gewiss das ein oder andere gegen Python 3 sagen (auch dazu kann man im Forum ausreichend viel nachlesen), aber dass es verwirrend ist, sicher nicht. Welches "vieles" meinst du denn? Das einzige, was mir einfällt, ist Verwechslungsgefahr von set-Literalen und dict-Literalen bei Verwendung der geschweiften Klammern.

[fabi1511]

das pass jetzt wirklich nicht in das thema, wie schon du schon gesagt hast, es gibt hier im forum genug darüber, also will ich das jetzt nicht weiter ausführen...

[Hyperion]

das pass jetzt wirklich nicht in das thema, wie schon du schon gesagt hast, es gibt hier im forum genug darüber, also will ich das jetzt nicht weiter ausführen...

Das ist jetzt aber schwach - Zur Not könnte man den Thread hier auftrennen, wenn es denn zu ausufernd würde, zum anderen bat Dich Numerix ja nur kurz ein paar Beispiel zu nennen...

Vorschlag zur Güte: Poste das einfach in einen vorhandenen Python3-Thread und verlinke den hier kurz

[Bloos]

vielen dank für die schnelle antworten
jetzt weiss ich was damit gemeint ist wenn man sagt python hat eine gute Community (*schleim**schleim*)

[fabi1511]

allgemein verwirrend finde ich nur weniges, was mich v.a. stört, ist, dass man viel alten code nicht mehr direkt verwenden kann, wie z.B.

Code: Alles auswählen

except KeyError, e

führt zu einem fehler, oder auch das angesprochene raw_input() und input(), was halt alles eine umstellung ist, die ich jetzt nicht benötige
(ich glaube gestern war einfach nicht mein tag der klaren ausdrücke )

ich find es nur blöd, das die abwärtskompatibilität gebrochen ist, ich weiß, die sprache musste "aufgeräumt" werden, aber ich finde die vielen neuerungen nicht so gut, aber ich habe mit python3 nicht viel erfahrung, weil ich wieder in die 2er serie gegangen bin, nachdem ich gemerkt habe, dass es keine mysql-lib gibt, wenn genügend bibliotheken vorhanden sind, und ich n bischen zeit habe, dann versuch ichs sicher nochmal mit python3

[DasIch]

dass es keine mysql-lib gibt

oursql hat einen py3k branch.

[cofi]

@fabi1511: Dich stoert wirklich das neue `except`Statement? Nie in ein `except KeyError, OSError`-Loch gefallen?

[BlackJack]

Die angesprochenen Änderungen werden doch auch vom 2to3-Skript problemlos behandelt, oder?

[jbs]

Ich finde die Verwendung von `as` in diesem Zusammenhang sehr gelungen.