Verfasst: Mittwoch 5. März 2008, 21:52
Deshalb habe ich ja in weiser Vorraussicht ein allgemeines OOP-Buch empfohlen. Wenn man das verstanden hat, sollte die geringe Umstellung auf Python nicht mehr die Schwierigkeit sein.
Seit 2002 Diskussionen rund um die Programmiersprache Python
https://www.python-forum.de/
Sorry, hätte nichts geschadet, wenn ich das Kapitel vorher mal gelesen hätte, bevor ich darauf verweise ... war mir nur spontan eingefallen beim Verweis auf das Openbook zur OOP.Ja, das Kapitel gibt einen guten Überblick darüber, wie man es falsch macht. Schade dass die dahinter nicht geschrieben haben "Haha, war alles nur Spaß, hier wie man das in Python machen würde: ...".
Wir müssen echt mal eine Seite im Wiki zu guten Python-Büchern anlegen. Das Problem ist ja, dass die Leute die auf Amazon bewerten nicht immer wissen, das das was sie im Openbook lesen manchmal ziemlicher Quatsch ist. Dennoch hat sich das Buch in der deutschen Community zu einer Massenware für Newbies entwickelt was ich nicht sonderlich toll finde.pütone hat geschrieben:Sorry, hätte nichts geschadet, wenn ich das Kapitel vorher mal gelesen hätte, bevor ich darauf verweise ... war mir nur spontan eingefallen beim Verweis auf das Openbook zur OOP.
Das wäre sicher hilfreich, denn es kommen ja doch öfter Fragen nach gedruckter deutschsprachiger Literatur. Bis es soweit ist, hilft vielleicht dem ein oder anderen dieser Link: http://www.way2python.de/pythonbuch/buecher.htmlLeonidas hat geschrieben:Eine Seite die gute Python-Bücher auflistet und sagt warum andere Bücher nicht so gut sind könnte IMHO gut helfen.
Naja, es waren genau drei, wobei ich das letzte noch nicht durch habe.pütone, du hast ja letztens scheinbar einige Einführungsbücher gelesen und kannst beurteilen ob sie aus sicher des Lernenden brauchbar sind und ob sie aus Sicht des Könnenden korrekt sind. Deine Hilfe wäre also gerne gesehen
Ja, wir sollten echt mal eine Wiki-Seite anlegen. So eine war zwar im alten Wiki, aber diesmal müssten wir es klarer formulieren, so dass der Einsteiger schneller sieht was empfehlenswert ist und was nicht.pütone hat geschrieben:Das wäre sicher hilfreich, denn es kommen ja doch öfter Fragen nach gedruckter deutschsprachiger Literatur. Bis es soweit ist, hilft vielleicht dem ein oder anderen dieser Link: http://www.way2python.de/pythonbuch/buecher.html
Das ist schon mal eine wertvolle Beobachtung - du könntest auch überlegen, das an den Verlag zu schicken, damit das Buch besser wird. Es ist ja durchaus keine Schade mal Fehler/Ungenauigkeiten zu haben, sofern man es dann besser machtpütone hat geschrieben:Dir würde z.B. gerade das von mir oben angepriesene Buch von M. Weigend vermutlich weniger gefallen, weil er konsequent von "Methoden" und "Attributen" spricht, statt alles "Attribute" zu nennen (da wäre Lutz/Ascher dann vorzuziehen). Auch verwendet Weigend konsequent file() statt open(), kennt noch keine Dekoratoren und behauptet, man könne Attribute (= Datenattribute) mittels __mydata sicher privatisieren - was so ja auch nicht stimmt.
Code: Alles auswählen
>>> file
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'file' is not defined
Das ist nicht lustig! ``file`` war für mich immer logischer als ``open``. Denn öffnen kann ich viel! Aber mit ``list`` bekomme ich eine Liste zurück. Mit ``dict`` bekomme ich ein Dictionary. Und mit ``file`` bekomme ich ein File.BlackJack hat geschrieben:@Leonidas: Da wird Dich Python 3.0 von "heilen":
Hallo!Code: Alles auswählen
>>> file Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'file' is not defined
Wovon leitet man dann ab? Oder muss man dann das Interface der ABCs aus PEP 3116 implementieren?BlackJack hat geschrieben:@Leonidas: Da wird Dich Python 3.0 von "heilen"
Da möchte ich dir uneingeschränkt zustimmen. Mir gefällt "file" auch viel besser als "open" - trotzdem benutze ich "open", weil es gemäß offizieller Doku eben so empfohlen wird. Im Hinblick auf Py 3000 sollte man sich eben dran gewöhnen.Gerold hat geschrieben:Das ist nicht lustig! ``file`` war für mich immer logischer als ``open``. Denn öffnen kann ich viel! Aber mit ``list`` bekomme ich eine Liste zurück. Mit ``dict`` bekomme ich ein Dictionary. Und mit ``file`` bekomme ich ein File.
Code: Alles auswählen
def Ausgabe(text):
textfenster.insert(END,'\n ' + text)
textfenster.see(END)
Ausgabe('\nerstelle csv Dateien')
while x < len(symbol_liste):
url=("http://ichart.yahoo.com/table.csv?s=%s&a=%s&b=%s&c=%s&d=%s&e=%s&f=%s&g=d&ignore=.csv" %(symbol_liste[x],Monatvon,Tagvon,Jahrvon,Monatbis,Tagbis,Jahrbis))
Ausgabe(url)
req = urllib.urlopen(url)
f = file("%stecdax\\%s.csv"%(pfad,symbol_liste[x]), 'w')
f.write(req.read())
f.close()
req.close()
Ausgabe(symbol_liste[x]+' erledigt')
x=x+1
Ausgabe('\nDateien aus Internet erstellt')
tkMessageBox.showinfo('Info',"TecDax eingelesen")
###main
textfenster = ScrolledText(root,background='white',font=('Verdana',10,'bold'))
textfenster.pack(expand=NO)
Siehst du, mir geht es genau umgekehrt, denn ...gerold hat geschrieben:``file`` war für mich immer logischer als ``open``.
... das, was ``file`` zurückgibt, ist in meinen Augen kein Dateiobjekt, da es lediglich den Inhalt wiederspiegelt. Ich erhalte über ``file``keinerlei Zugriff auf die Metainformationen einer Datei (Größe, Rechte, Eigentümer, etc.), obwohl all diese Dinge klar mit einer Datei verbunden sind. Mehr noch, der Name ``file`` verbirgt den Zweck des zurückgegebenen Objekts.Denn öffnen kann ich viel! Aber mit ``list`` bekomme ich eine Liste zurück. Mit ``dict`` bekomme ich ein Dictionary. Und mit ``file`` bekomme ich ein File.
Es ist durchdacht, eines der beiden Duplikate zu entfernen. Welches das letztendlich ist, kann einem doch eigentlich egal sein Ich halte ``file`` für die überflüssige Variante... wenn du das anders siehst, bitte:``file = open`` steht dir ja frei.Das Abschaffen von ``file`` ist wieder so ein Beispiel dafür, das mich glauben lässt, dass Python 3.0 nicht wirklich gut durchdacht sein wird.
Glücklicherweise sind wir nicht in der Mathematik, so dass niemand gezwungen ist, in deiner subjektiven Meinung tatsächlich eine Logik zu erkennen.Es wäre wohl eher eine logische Konsequenz gewesen, ``open`` zu lassen und ``file`` zu forcieren. Aber was soll's.
Hallo lunar!lunar hat geschrieben:... das, was ``file`` zurückgibt, ist in meinen Augen kein Dateiobjekt, da es lediglich den Inhalt wiederspiegelt. Ich erhalte über ``file``keinerlei Zugriff auf die Metainformationen einer Datei (Größe, Rechte, Eigentümer, etc.)Denn öffnen kann ich viel! Aber mit ``list`` bekomme ich eine Liste zurück. Mit ``dict`` bekomme ich ein Dictionary. Und mit ``file`` bekomme ich ein File.
Das steht dann auch im nächsten Kapitel:Leonidas hat geschrieben:Ja, das Kapitel gibt einen guten Überblick darüber, wie man es falsch macht. Schade dass die dahinter nicht geschrieben haben "Haha, war alles nur Spaß, hier wie man das in Python machen würde: ...".
Müssen wir diese Diskussion in jedem Thread wiederholen? Schau doch einfach nach was bereits gesagt wurde.pot hat geschrieben:Ich hab' es mir zwar nicht wirklich durchgelesen, bin jedoch nicht so erfahren das zu bestätigen. Was ist denn daran so falsch?
Dann aber zwecks Konsistenz bitte auch ``fileopen`` oder ``FileStream`` anstatt ``file``... und dann sind wir vollends bei .NET angekommengerold hat geschrieben:Hallo lunar!lunar hat geschrieben:... das, was ``file`` zurückgibt, ist in meinen Augen kein Dateiobjekt, da es lediglich den Inhalt wiederspiegelt. Ich erhalte über ``file``keinerlei Zugriff auf die Metainformationen einer Datei (Größe, Rechte, Eigentümer, etc.)Denn öffnen kann ich viel! Aber mit ``list`` bekomme ich eine Liste zurück. Mit ``dict`` bekomme ich ein Dictionary. Und mit ``file`` bekomme ich ein File.
Für die Metainformationen einer Datei wäre dann ``fileinfo`` zuständig.