OOP für Dummy's
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: ...".
Naja, dann wissen wir jetzt wenigstens, wo man nachlesen kann, wie man es nicht machen sollte.
@sea-live:
Es wäre wirklich hilfreich, wenn du dich wenigstens tendenziell an der deutschen Rechtschreibung orientieren könntest - das macht es wesentlich leichter, deine Postings zu lesen und auch zu verstehen.
In einem deiner ersten Postings in einem früheren Thread hast du geäußert, du wärest begeistert von Python. Geht mir auch so. Aber dann verstehe ich nicht, warum du dir nicht die Mühe machst, dich erstmal gründlich mit Python und auch dem OOP-Teil von Python zu beschäftigen, bevor du dich an Programme dieser Art und dieses Umfangs in einer für ich bis vor ca. 3 Wochen unbekannten Programmiersprache begibst.
Sicher, man kann auch ganz ohne OOP in Python programmieren (und gerade das macht es Umsteigern von der imperativen/prozeduralen Programmierung relativ leicht, zunächst einen guten Einstieg in Python zu finden), aber - und darauf wurdest du in einem anderen Thread schon hingewiesen - eine GUI-Anwendung ohne wirkliches Verständnis in die OOP zu programmieren ist nicht besonders sinnvoll.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.
Eine Seite die gute Python-Bücher auflistet und sagt warum andere Bücher nicht so gut sind könnte IMHO gut helfen. 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
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
An Hilfsbereitschaft würde es nicht mangeln, die Sicht des Lernenden habe ich sicher, aber eben (noch ...) nicht die des Könnenden. Daran arbeite ich - mit eurer tatkräftigen Unterstützung - ja zur Zeit noch.
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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.
P.S.: Ich verwende in meiner Sturheit auch öfter ``file`` als ``open``
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@Leonidas: Da wird Dich Python 3.0 von "heilen":
Code: Alles auswählen
>>> file
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'file' is not defined
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
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
``open`` war für mich immer schon "unlogisch". Und ich freute mich sehr, als ich herausfand, dass man mit ``file`` ein File-Objekt erzeugen kann.
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. Es wäre wohl eher eine logische Konsequenz gewesen, ``open`` zu lassen und ``file`` zu forcieren. Aber was soll's.
Ich bin nicht in die Entwicklung involviert und die anderen Spinner (sorry) werden erst drauf kommen, wenn sie ein zweites .NET geschaffen haben.
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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"
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Also ich finde so eine Fabrikfunktion praktischer als `io` importieren zu müssen und da die richtige Klasse zu "suchen". Wenn man damit anfängt, dann ist es nicht mehr weit bis Java.
Es gibt in 3.0 nicht mehr ein `file` für alles, sondern verschiedene Klassen für Binärdaten und Text mit eingebauter Konvertierung von/nach Unicode. Ein ``open('text.txt')`` liefert eine zum lesen geöffnete Textdatei mit UTF-8-Kodierung.
Es gibt in 3.0 nicht mehr ein `file` für alles, sondern verschiedene Klassen für Binärdaten und Text mit eingebauter Konvertierung von/nach Unicode. Ein ``open('text.txt')`` liefert eine zum lesen geöffnete Textdatei mit UTF-8-Kodierung.
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.
Aber gefallen tut mir das nicht.
Es Läuft
Leute ich habs 4 Tage und das letzte Tutorial hats gebracht
so als nächstes were ich tkinter dann rauswerfen und alles in wxPython fummeln
es gibt da in der DEMO auswahl für Kalender und Filesystem
das wird sicherlich toll für mich
DANKE an die FREAKS und OOP ASSE
programme
http://www.euroschall.de/boerse_V1-3.rar
screenshot
Leute ich habs 4 Tage und das letzte Tutorial hats gebracht
so als nächstes were ich tkinter dann rauswerfen und alles in wxPython fummeln
es gibt da in der DEMO auswahl für Kalender und Filesystem
das wird sicherlich toll für mich
DANKE an die FREAKS und OOP ASSE
programme
http://www.euroschall.de/boerse_V1-3.rar
screenshot
BITTE BITTE noch ein TIP
Wie schaff ich es das bei Jedem internet Rückgabewert das gleich angezeigt wird
Beim Einlesen liest das Programm alle Werte erst ein und bringt dann alles was Gemacht wurde zur ausgabe
sollte aber Ständig das Ausgeben was es zur Zeit macht,
Wie schaff ich es das bei Jedem internet Rückgabewert das gleich angezeigt wird
Beim Einlesen liest das Programm alle Werte erst ein und bringt dann alles was Gemacht wurde zur ausgabe
sollte aber Ständig das Ausgeben was es zur Zeit macht,
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.
``open`` dagegen drückt klar aus, dass es in diesem Fall nicht um Metainformationen geht, sondern allein darum, die Datei zum Lesen oder Schreiben des Inhalts zu öffnen. Hier ist der thematische Zusammenhang imho wesentlich klarer.
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.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
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.
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
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: ...".
http://www.galileocomputing.de/openbook ... .htm#t2t32
Grüsse
Pot
@pot: Ich glaube Du hast es nicht ganz verstanden: Den Link, den Du da angibst, da fängt es ja gerade an schrecklich zu werden! Ab da wird gezeigt wie man OOP in Python *nicht* machen sollte.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.