Auch wenn es schon in einem Thread erwähnt wurde, glaube ich, dass es hier trotdem nochmal rein sollte.
Das Buch ist zum Download unter
http://www.galileocomputing.de/openbook/python/
verfügbar.
Python - Das umfassende Handbuch
IMHO: Das Buch ist Müll. Ich habe mit dem OOP Kapitel angefangen und da wird gleich `__del__()` als Destruktor vorgestellt, ohne jegliche Warnung warum man das nicht benutzen sollte, und "private members" mit doppelten führenden Unterstrichen um "private" Daten vor Zugriff zu schützen und sinnlose, triviale Getter und Setter per `property()` um dann darauf zuzugreifen. Argh!
In `12.4 Objektphilosophie` wird gesagt wie toll OOP ist und alles einfacher zu entwickeln und wieder zu verwenden ist. Am Beispiel einer `durchschnitt()`-Methode in einer Klasse, die von `list` erbt und mit `type()` die Elemente überprüft, ob sie `int` oder `float` sind. Doppel-Argh! Von Listen mit `long`- oder `Decimal`-Objekten kann man also damit keinen Durchschnitt bilden. Toll! Und irgendwie ist eine Funktion die den Durchschnitt von *jedem* "iterable" berechnet IMHO wesentlich flexibler wieder verwendbar als diese Klasse.
In `12.4 Objektphilosophie` wird gesagt wie toll OOP ist und alles einfacher zu entwickeln und wieder zu verwenden ist. Am Beispiel einer `durchschnitt()`-Methode in einer Klasse, die von `list` erbt und mit `type()` die Elemente überprüft, ob sie `int` oder `float` sind. Doppel-Argh! Von Listen mit `long`- oder `Decimal`-Objekten kann man also damit keinen Durchschnitt bilden. Toll! Und irgendwie ist eine Funktion die den Durchschnitt von *jedem* "iterable" berechnet IMHO wesentlich flexibler wieder verwendbar als diese Klasse.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Erstaunlich, dass in jedem Thread zu diesem Buch irgendwelche Fehler gefunden werden (auch von mir, also nicht als Kritik gedacht).
Nun scheint Galileo Computing ein sehr netter Verlag zu sein, aber die Bücher sind oft nicht so toll - ich höre auch immer wieder Kritik am Java-Buch.
Was mich immer wundert ist, wer diese Bücher schreibt. Das sind fast immer totale Community-Outsider von denen ich nie gehört habe. Das könnte ein Kritikpunkt sein, denn ich kenne viele Leute in der Community, die wirklich ausreichend Ahnung haben, um so ein Buch zu verfassen.
Oder ist es eine Verlagssache? O'Reilly-Bücher waren früher sehr gut, inzwischen sind nicht mehr alle uneingeschränkt empfehlenswert. Apress scheint aber ganz gute Bücher herauszugeben ebenso Packt Publishing.
Nun scheint Galileo Computing ein sehr netter Verlag zu sein, aber die Bücher sind oft nicht so toll - ich höre auch immer wieder Kritik am Java-Buch.
Was mich immer wundert ist, wer diese Bücher schreibt. Das sind fast immer totale Community-Outsider von denen ich nie gehört habe. Das könnte ein Kritikpunkt sein, denn ich kenne viele Leute in der Community, die wirklich ausreichend Ahnung haben, um so ein Buch zu verfassen.
Oder ist es eine Verlagssache? O'Reilly-Bücher waren früher sehr gut, inzwischen sind nicht mehr alle uneingeschränkt empfehlenswert. Apress scheint aber ganz gute Bücher herauszugeben ebenso Packt Publishing.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Das einige in der Lage sind, heißt nicht das sie das machen. Ich kann jetzt nur für Python sprechen aber mir ist schon öfters aufgefallen das Codebeispiele, Dokumentationen die von irgentwelchen Autoren von Zeitschriften (sei es ix, ct oder Linux-Zeitschriften, alle gleich) sehen in den meißten Fällen entweder so aus, als ob die ihren Code noch nie öffentich gezeigt haben oder ob sie frisch Python gelernt haben um nen Artikel zu schreiben.Leonidas hat geschrieben:Das könnte ein Kritikpunkt sein, denn ich kenne viele Leute in der Community, die wirklich ausreichend Ahnung haben, um so ein Buch zu verfassen.
Es gibt wirklich nur wenige Python-Bücher die wirklich was bringen, jedoch noch weniger welche die auch bestimmte "Das macht man nicht" - Sachen einhalten. PEPs zum Beispiel, ich (hab nicht alles gelesen) habe bis jetzt noch kein Buch gesehen, welches auch nur im Entferntesten PEP08 umsetzt. Warum nicht?
Was man braucht wird wohl ne gute Community-Aktion sein und nen guten Verleger, oder einfach mal jemand der das Englische Tutorial übersetzt (welches recht gut ist, finde ich).
MfG EnTeQuAk
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Hat Dinu Gherman mal gemacht, es ist nur inzwischen auf dem Stand von Python 1.5, also etwas veraltet. Aber das aktuelle Tutorial gibt es übrigens auf Papier in Englisch zu kaufen.EnTeQuAk hat geschrieben:oder einfach mal jemand der das Englische Tutorial übersetzt (welches recht gut ist, finde ich).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Wenn noch nicht mal die stdlib PEP 8 vollständig einhält, dann kann man das nur bedingt von Buchautoren fordern.EnTeQuAk hat geschrieben:Es gibt wirklich nur wenige Python-Bücher die wirklich was bringen, jedoch noch weniger welche die auch bestimmte "Das macht man nicht" - Sachen einhalten. PEPs zum Beispiel, ich (hab nicht alles gelesen) habe bis jetzt noch kein Buch gesehen, welches auch nur im Entferntesten PEP08 umsetzt. Warum nicht?
Bei anderen Sprachen sieht es übrigens nicht wirklich besser aus. Dutzende C Bücher empfehlen gets als Funktion zum Lesen von stdin. Dutzende C++ Bücher machen immer noch '#include <iostream.h>', und Suns Styleguide für Java findet auch nur in den seltensten Fällen Anerkennung bei den Java-Autoren.
Vernünftige C++ oder C (mal abgesehen von Stroustrup und K&R) Bücher zu finden, ist auch nicht wirklich leicht.
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
Und genau solche Bücher werden dann von Schule als Lehrmittel verwendet und von Lehrern vergöttert. Smashing the stack against boredom...lunar hat geschrieben:Bei anderen Sprachen sieht es übrigens nicht wirklich besser aus. Dutzende C Bücher empfehlen gets als Funktion zum Lesen von stdin.
Ich fand den C++ Primer ganz nett.lunar hat geschrieben: Vernünftige C++ oder C (mal abgesehen von Stroustrup und K&R) Bücher zu finden, ist auch nicht wirklich leicht.
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Das ist nicht nur in der Schule so, dass zieht sich hoch bis an die Universitäten. Im Maschinenbaustudium an der "Eliteuni" TU München steht im Skript für Erstsemester Softwareentwicklung "Verwenden sie gets,um eine Eingabe von der Konsole einzulesen". Das lag bei nem Freund auf dem Schreibtisch, als ich das gelesen habe, hätte ich den Professor am liebsten erschlagen.veers hat geschrieben:Und genau solche Bücher werden dann von Schule als Lehrmittel verwendet und von Lehrern vergöttert. Smashing the stack against boredom...lunar hat geschrieben:Bei anderen Sprachen sieht es übrigens nicht wirklich besser aus. Dutzende C Bücher empfehlen gets als Funktion zum Lesen von stdin.
Ich muss den Thread nochmal ausgraben. Ich bin zwar kein absoluter Anfänger, aber ich muss noch einiges lernen.
Und ich kämpfe mit genau dieser Problematik. Woher soll man lernen wie es "richtig" ist? Vor allem wenn man sich mit englischen Dokumentationen schwer tut. Man kann eigentlich nur entweder Bücher kaufen oder Tutorials lesen und hoffen das es schon irgendwie stimmt.
Dabei habe ich aber immer wieder das Problem das in drei Beschreibungen für das gleiche Problem drei unterschiedliche Methoden angewandt werden. Woher soll man als Anfänger wissen welche davon "richtig" ist oder ob überhaupt eine richtig und nicht eine vierte die man noch nicht kennt?
Ich hab mich mal an der englischen Doku versucht, bin aber nicht weit gekommen. Wie also sollte man es lernen wenn man sich nichtmal auf solche Bücher wie das von Galileo verlassen kann?
Und ich kämpfe mit genau dieser Problematik. Woher soll man lernen wie es "richtig" ist? Vor allem wenn man sich mit englischen Dokumentationen schwer tut. Man kann eigentlich nur entweder Bücher kaufen oder Tutorials lesen und hoffen das es schon irgendwie stimmt.
Dabei habe ich aber immer wieder das Problem das in drei Beschreibungen für das gleiche Problem drei unterschiedliche Methoden angewandt werden. Woher soll man als Anfänger wissen welche davon "richtig" ist oder ob überhaupt eine richtig und nicht eine vierte die man noch nicht kennt?
Ich hab mich mal an der englischen Doku versucht, bin aber nicht weit gekommen. Wie also sollte man es lernen wenn man sich nichtmal auf solche Bücher wie das von Galileo verlassen kann?
http://www.amazon.de/Objektorientierte- ... 82661660X/
Ist auf dem Stand von 2.4, das Kapitel über XML ist doof und der benutzt File-Objekte anstatt open und öfter mal sind die Variablen Namen nicht so richtig toll.
Aber ich finds ganz gut, man sollte nur dannach fix PEP8 lesen
Ist auf dem Stand von 2.4, das Kapitel über XML ist doof und der benutzt File-Objekte anstatt open und öfter mal sind die Variablen Namen nicht so richtig toll.
Aber ich finds ganz gut, man sollte nur dannach fix PEP8 lesen
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Natürlich, ein Problem hat mehrere Lösungen (außer in Python, wo es immer nur eine gibt *g*) und viele sind ja auch äquivalent. Wenn du dir nicht sicher bist, kannst du als Anfänger natürlich jederzeit erfahrenere Leute fragen, etwa die hier im Forum. Manchmal können sich aus solchen Fragen auch schöne Diskussionen entwickeln und dann haben alle was davon.burli hat geschrieben:Dabei habe ich aber immer wieder das Problem das in drei Beschreibungen für das gleiche Problem drei unterschiedliche Methoden angewandt werden. Woher soll man als Anfänger wissen welche davon "richtig" ist oder ob überhaupt eine richtig und nicht eine vierte die man noch nicht kennt?
Also keine Scheu. Wenn du die Dokumentation gelesen hast (Wie ein Informatiker denken lernen... soll ganz gut sein, außerdem gibt es A Byte of Python auch in Deutsch. Ansonsten solltest du dir wirklich das englische Python-Tutorial ansehen, das zeigt quasi immer den zu bevorzugenden Weg) dann kannst du durchaus Fragen stellen ohne dass dir der Kopf abgerissen wird.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Das ist doch mal was, danke. Was aber nicht schlecht wäre ist eine Zusammenfassung von den wichtigsten "Verhaltensregeln". Sowas finde ich eigentlich immer recht hilfreich. Gibt es sowas? Und wenn nicht, könnte man sowas nicht mal erstellen? So eine Art "Do's and Dont's" für Python
Und schon geht es wieder los. Ich hab die Texte nur mal grob überflogen und zufällig eine Unstimmigkeit entdeckt.
In PEP8 steht:
Weiterhin hab ich in PEP8 gelesen man soll alle Imports an den Anfang einer Datei stellen. In manchen Fällen wäre es aber sinnvoll wenn Imports je nach Situation auch nicht importiert werden um Ladezeit zu sparen.
Ich weiß das PEP keine zwingenden Vorgaben sondern nur Empfehlungen, aber wie soll man entscheiden wann man die Empfehlungen ignorieren kann?
In PEP8 steht:
In der deutschen Übersetzung wird jedoch empfohlen wegen den möglichen Umlauten in Strings oder Kommentaren die UTF-8 Kodierung zu verwendenCode in the core Python distribution should aways use the ASCII or
Latin-1 encoding (a.k.a. ISO-8859-1). For Python 3.0 and beyond,
UTF-8 is preferred over Latin-1, see PEP 3120.
#!/usr/bin/python
# -*- coding: utf-8 -*-
print 'Käse!' # kein Problem mehr
Weiterhin hab ich in PEP8 gelesen man soll alle Imports an den Anfang einer Datei stellen. In manchen Fällen wäre es aber sinnvoll wenn Imports je nach Situation auch nicht importiert werden um Ladezeit zu sparen.
Ich weiß das PEP keine zwingenden Vorgaben sondern nur Empfehlungen, aber wie soll man entscheiden wann man die Empfehlungen ignorieren kann?
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Welche deutsche Übersetzung meinst du denn? Von PEP8?
Der von dir gepostete Abschnitt bezeichnet ja nur Code, der in die Stdlib soll, also Teil von Python werden soll. Ich kodiere meine Python-Programme generell in UTF-8 und werde das auch so beibehalten, insbesondere da das mit Python 3.0 sowieso bevorzugt wird.
PEPs sind durchaus zwingende Empfehlungen und zwar über die Zukunft von Python. PEP8 ist da sozusagen "nur aus Zufall" drin, weil er eigentlich bezeichnet wie der Code in der Stdlib auszusehen hat. Wie dein Code aussieht ist ihm egal. Aber dennoch ist es sinnvoll sich an PEP8 zu halten, richtig. Ich habe nur eine Ausnahme für mehrere Imports in einer Zeile, das ist alles. Der Rest meines Codes ist ziemlich genau PEP8-konform.
Der von dir gepostete Abschnitt bezeichnet ja nur Code, der in die Stdlib soll, also Teil von Python werden soll. Ich kodiere meine Python-Programme generell in UTF-8 und werde das auch so beibehalten, insbesondere da das mit Python 3.0 sowieso bevorzugt wird.
PEPs sind durchaus zwingende Empfehlungen und zwar über die Zukunft von Python. PEP8 ist da sozusagen "nur aus Zufall" drin, weil er eigentlich bezeichnet wie der Code in der Stdlib auszusehen hat. Wie dein Code aussieht ist ihm egal. Aber dennoch ist es sinnvoll sich an PEP8 zu halten, richtig. Ich habe nur eine Ausnahme für mehrere Imports in einer Zeile, das ist alles. Der Rest meines Codes ist ziemlich genau PEP8-konform.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Äh, sorry. Die Übersetzung von "A Byte of Python" war gemeint. Seite 21/22
Es sind halt immer diese Widersprüche über die ich stolpere und dann nicht weiß was ich eigentlich machen soll. Prinzipiell kann ich ja programmieren wie ich Lust hab, aber ich will es wenigstens halbwegs vernünftig machen
Edit (Leonidas): Restliche Diskussion nach "Properties und Setters" abgetrennt.
Es sind halt immer diese Widersprüche über die ich stolpere und dann nicht weiß was ich eigentlich machen soll. Prinzipiell kann ich ja programmieren wie ich Lust hab, aber ich will es wenigstens halbwegs vernünftig machen
Edit (Leonidas): Restliche Diskussion nach "Properties und Setters" abgetrennt.
Hallo,
vor ein paar Tagen habe ich jenes besagte Buch entdeckt. Zwar habe ich noch nichts darin gelesen, und bin somit auf jene Fehler noch nicht aufmerksam geworden; jedoch hat es auf mich hinsichtlich der behandelten Themen einen guten Eindruck gemacht. Darum würde ich es jetzt nicht gleich als Müll bezeichnen.
mfg
vor ein paar Tagen habe ich jenes besagte Buch entdeckt. Zwar habe ich noch nichts darin gelesen, und bin somit auf jene Fehler noch nicht aufmerksam geworden; jedoch hat es auf mich hinsichtlich der behandelten Themen einen guten Eindruck gemacht. Darum würde ich es jetzt nicht gleich als Müll bezeichnen.
mfg
Ich habe es ja auch nicht Aufgrund der Themenauswahl als Müll bezeichnet, sondern aufgrund des *Inhalts* des OOP-Teils. Da OOP eine wichtige Sache in Python ist, und dieses Kapitel echt grausam "unpythonisch" ist, taugt es IMHO nicht um Python zu lernen.
PEPs im Allgemeinen und PEP8 im Besonderen sind schon etwas mehr als Empfehlungen, man sollte sie auch nicht leichtfertig ignorieren! Wenn man sich allerdings bewusst ist, was man tut, so ergeben sich durchaus Situationen, in denen manche Gebote des PEP 8 nicht sinnvoll sind.burli hat geschrieben:Ich weiß das PEP keine zwingenden Vorgaben sondern nur Empfehlungen, aber wie soll man entscheiden wann man die Empfehlungen ignorieren kann?
Um das Beispiel der Imports aufzugreifen: Es ist bei Modulen eigentlich immer sinnvoll, die Imports an den Anfang zu stellen. Aber es gibt eben auch Ausnahmen, wie z.B. ein Script, welches auch als Model verwendet werden soll. Das Script benötigt Dinge wie eine Bibliothek zum Parsen der Kommandozeilen-Argumente oder einen Signal-Handler für SIGINT, an denen der Programmierer, der das Modul importieren will, nicht unbedingt interessiert ist. Solche Imports kann man sehr wohl an den Anfang der main()-Funktion stellen, so dass das Modul auch benutzbar ist, wenn z.B. die Parser-Bibliothek gar nicht installiert ist.
Moin moin,
das bisher so unbeliebte OpenBook von Galilio wurde offensichtlich ausgetauscht. Der Link verweist jetzt auf ein Buch anderen Titels mit zwei anderen Autoren.
http://www.galileocomputing.de/openbook/python/
Ich kann und will noch keine Bewertung abgeben, aber der "alte Müll" ist das definitiv nicht. Den habe ich bei Galileo als OpenBook auch nicht mehr gefunden.
Gruß - Uwe
das bisher so unbeliebte OpenBook von Galilio wurde offensichtlich ausgetauscht. Der Link verweist jetzt auf ein Buch anderen Titels mit zwei anderen Autoren.
http://www.galileocomputing.de/openbook/python/
Ich kann und will noch keine Bewertung abgeben, aber der "alte Müll" ist das definitiv nicht. Den habe ich bei Galileo als OpenBook auch nicht mehr gefunden.
Gruß - Uwe