Aller Anfang ist schwer

[loki]

Hallo ihr Schlangenliebhaber

Meine Frage lässt sich in einem Satz formulieren (weitere Details gibt es unten): Ich möchte sehr gerne Python lernen, wie gehe ich am Besten vor?

Ich befinde mich derzeitig in dem Abschlussjahr von meiner Ausbildung als Mediengestalter Non-Print. Von daher kenne ich mich ein wenig mit Programmierung aus. Ich kann Html, Css, bisschen XML, Lingo (sprache von Macromedias Director). Sprachen wie JavaScript, PHP etc. haben wir damals in der Schule kurz durchgenommen, daher würde ich nicht sagen, dass ich diese Sprachen beherrsche, dennoch aber einen leichten Überblick finde... Ich selbst hab nen Mac.

Ich würde mit Python kleine Spielereien programmieren, Webkram, und vor allem für Cinema 4D hernehmen. Da kann man coole
Sachen mit machen

Css und Html hab ich (obwohl wir das in der Schule durchgenommen haben) größtenteils selbst beigebracht.
Da gibts ja massig How-To´s. Bei Python gestaltet sich das ganze dann doch wieder ganz anders .

Wie fange ich am Besten an? Ich bin auch bereit, Bücher zu kaufen. Sollte ich mit Python 3.xyz anfangen oder
doch dem Standard 2.7.2?

Ich hoffe ihr seid nicht von diesem Thema genervt oder andernweitig erbost, sonst lerne ich eine andere Sprache: Spanisch

Loki,



Bedankt sich im Voraus

[The Spirit]

fang am besten mit dem offiziellen tutorial von pyton.org an.
ich hab dir mal das tut für 2.7.2 hier verlinkt
http://docs.python.org/tutorial/index.html

ob du lieber mit 2.7.2 oder 3.x anfängst hängt eher davon ab, welche packages du später mal brauchst.
aber momentan machst du sicher mit 2.7.2 nix falsch.

[Hyperion]

Ein guter Anfang wäre es, einfach mal per Suchfunktion alle möglichen Threads zu diesem Thema durchzulesen. Da erfährst Du die verschiedenen Standpunkte bezüglich Python 2 vs Python 3, GUI Programmierung zu Beginn ja oder nein, welche Bücher (Galileo Verlag - Ernesti / Kaiser) schlecht sind, welche Tuts zu empfehlen sind, usw. Ich denke da kommt einiges hilfreiches zusammen

[MikeDee]

Ein sehr gutes Tutorial, wie ich finde, ist http://www.rg16.asn-wien.ac.at/~python/ ... /index.htm

[problembär]

Am besten Du fängst überhaupt an.
Z.B. mit

Code: Alles auswählen

print "Hallo Welt."

Das war Python 2.x. Laß' das laufen und betrachte das Ergebnis. Der Rest entwickelt sich dann.

[loki]

Am besten Du fängst überhaupt an.
Z.B. mit

Code: Alles auswählen

print "Hallo Welt."

Das war Python 2.x. Laß' das laufen und betrachte das Ergebnis. Der Rest entwickelt sich dann.

danke, dass ihr schon so schnell geantwortet habt
da waren auch sehr gute tipps mit dabei.
ich sollte noch erwähnen, dass ich python bereits als taschenrechner benutzen kann
habt ihr noch ein paar sehr gute buchtipps?

vielen dank

[loki]

Ich weiß, doppelposts sind verboten, aber hat denn keiner einen Buchtipp für eine Anfängerschlange?

[deets]

http://learnpythonthehardway.org/

Prophylaktischer Hinweis: Und auch wenn's bloed klingt - englisch ist als Programmierer ein muss, nimm's als Motivation, wegen des programmierens dein Englisch zu verbessern.

[VanChriz]

Nutze jetzt seit einer Weile ein Python-Buch von Galileo (Einstieg in Python von T. Theis). Habe jetzt schon mehrmals im Forum gesehen, dass hier die Meinung zu Galileo-Kram eher meh ist, aber war das mehr auf das openbook bezogen oder auf alle Pythonbücher des Verlags?
Mfg, Chris

[Tom_H]

Jetzt werden mich ein paar Schlangenhüter gleich verhauen...
Python ist als "Lern-Sprache" IMHO eher weniger geeignet, weil dieser Interpreter ohne zu meckern doch so ziemlich alles abarbeitet, was nur irgendwie nach Python-Code aussieht. Da kann man wunderbar logische Fehler verstecken und sehr viel (frustrierende) Zeit mit der Fehlersuche verbringen.
Für den "blutigen Anfang" würde ich mal einen streng prozeduralen Vertreter der Spezies Programmiersprachen empfehlen. Am besten eine Compiler-Variante, die strengstens mit Typen und Referenzen umgeht - das schult die Präzision und bewahrt vor schwer auffindbaren Fehlern. Heute würde ich (auch wegen der Verbreitung) auf C setzen. Wenn man C (vorerst mal ohne +) lesen und schreiben kann, ist das auch für die Zukunft sicher nicht verkehrt (wobei mir persönlich die Syntax nicht sonderlich gut gefällt - aber das ist ein anderes Thema).
Mit Objekten und Methoden sollte man sich IMHO erst dann beschäftigen, wenn man die Grundlagen (Prozeduren, Funktionen, endliche Automaten) verstanden hat.

mfg, Tom

[cofi]

@Tom_H: Das ist ein ziemliches Statement. Hast du auch Beispiele, um deine Aussagen zu untermauern, dass Python "so ziemlich alles abarbeitet"?
Logische Fehler wird eine Sprache _nie_ abfangen (Teilmengen davon durchaus, aber evtl zu hohen Kosten). Gerade C ist die falsche Richtung. C wurde konzipiert, um das Schreiben eines Compilers einfach zu machen, nicht die Benutzung. Das merkt man, wenn man sich die Spezifikation anschaut und mal zaehlt wo ueberall der Begriff "undefiniertes Verhalten" oder "compilerspezifisches Verhalten" auftaucht. Und es gibt keine Compiler Variante die das fuer C so macht wie du es beschreibst ...

Wenn wir denn eine Sprache zum Einstieg erwaehnen wollen, die kein Python ist, ist das meiner Meinung nach Scheme und erst recht keine imperative Sprache.

[VanChriz]

Oh sorry, hätte ich erwähnen sollen. Habe vor etwa einem Jahr mit C angefangen zu coden. Als es mir nach einer Zeit zu kompliziert wurde, hab ich gewechselt und auf Webspiders Empfehlung mit Python angefangen. Ich komme mit dem Galileo Einstieg in Python eigentlich ganz gut zurecht, auch wenns natürlich ein relativ langes buch ist. Wollte hier nur nochmal die allgemeine Meinung zu Galileo-Büchern abseits des Openbooks einholen.

[BlackJack]

@Tom_H: Was arbeitet Python denn ohne zu meckern ab, ausser syntaktisch und semantisch korrektes Python? Python ist relativ streng typisiert — wenn man einen Typfehler im Programm hat, wird einem das recht deutlich gesagt.

Bei statisch typisierten Sprachen die so richtig strengstens mit Typen umgehen, kann es dagegen für Anfänger sehr frustrierend sein erst mal den Compiler zufrieden zu stellen, bevor man das Programm überhaupt erst einmal ausprobieren kann. Und auch da raten dann Anfänger oft einfach herum bis sie etwas gefunden haben was der Compiler nicht beanstandet. Das kann dann trotzdem fehlerhaft sein. Und wird es in vielen Fällen auch. Wie cofi ja schon sagte, finden Compiler nicht alle Logikfehler. Die Logik ist aber genau das was Anfänger lernen müssen.

Warum streng prozedural? Viele Unis fangen zum Beispiel mit funktional an. Damit sollen auch sehr viele, die noch nicht „prozedural verdorben“ sind, sehr gut einsteigen können.

Bei C ist die Frage ob man heutzutage wirklich auf Maschinenebene anfangen sollte, oder nicht vielleicht doch lieber eine Hochsprache lernt. Das ist so unbenutzbar für „normale“ Aufgaben und bei Fehlern extrem frustrierend. Man sollte Anfänger bei Fehlern keine Speicherzugriffsverletzungen melden, sondern eine ordentliche Fehlerbeschreibung und einen Stapelabzug, der auf die Fehlerzeile hinweist. Wobei man auch Pech haben kann und das Programm gar nicht abstürzt, sondern Daten verändert, die dann an ganz anderer Stelle zu Problemen führen.

[BlackJack]

@VanChriz: Ich glaube es gab an dem Buch von Theis auch was auszusetzen. Kann ich aber nicht beschwören und ich finde es gerade nicht.

Das die Bücher aus dem Verlag generell schlecht sind, kann man nicht sagen, aber man muss wohl vorsichtig sein, und sich vorher erkundigen. Das „C von A - Z“ soll zum Beispiel gut sein.

[VanChriz]

Ok, habe mich jetzt nochmal ein wenig umgesehen und die Meinungen zu Theis' Einstieg in Python scheinen wesentlich besser zu sein, außer der Tatsache das das Buch nur in den ersten Kapiteln Aufgaben stellt. Kann ich bestätigen, die Aufgaben dürften länger fortgeführt werden. Aber wenn ich mit dem Buch durch bin, widme ich mich noch learn python the hard way, da eben doch alles unterschiedlich erklärt wird und es so nicht schaden dürfte

[Tom_H]

@Tom_H: Was arbeitet Python denn ohne zu meckern ab, ausser syntaktisch und semantisch korrektes Python? Python ist relativ streng typisiert — wenn man einen Typfehler im Programm hat, wird einem das recht deutlich gesagt.

Okok - Du hast Recht - generell ist die Typprüfung in Python schon recht streng. Das sollte auch einen Anfänger vor grobem Unbill bewahren.

Ich bin alter Pascalianer der ersten Stunde - bei "True == 1" bekomm' ich graue Haare. Ein Boolean ist kein Integer (das ist aber keine Python-Eigenart - sehr viele Sprachen behandeln False und Null gleichwertig).
Die stillschweigende float/int-Conversion kann auch viele Stunden Fehlersuche bescheren - da wären dann vordeklarierte Typen eindeutig im Vorteil.
Die Python-Regeln, wann Referenzen und wann Werte übergeben werden, sind mir bis heute nicht klar - und den meißten Anfängern wahrscheinlich auch nicht. Hier ist IMHO ein breites Betätigungsfeld für Seiteneffekte (und ganz schwer auffindbare Programm-Fehler).

Aber es gibt wohl in jeder Sprache ein paar Fallstricke, die man mehr oder weniger mühsam erkennen muß. Ich wollte weder Python schlecht reden, noch eine "Was ist Besser"-Diskussion entfachen. Wenn ich nicht selbst auch in Python schreiben würde, wäre ich nicht hier.
Ich habe übrigens mit Fortran-77 auf Lochkarten an einer CDC-6500 angefangen.

mfg, Tom

[BlackJack]

@Tom_H: Nunja in Python ist ein Boolean nun mal ein Integer. Das ist aber von den Typen her ziemlich klar geregelt, denn die Boolean-Klasse ist eine Unterklasse von `int`:

Code: Alles auswählen

In [267]: issubclass(bool, int)
Out[267]: True

In [268]: isinstance(True, bool)
Out[268]: True

In [269]: isinstance(True, int)
Out[269]: True

Das kann man mögen, oder auch nicht, aber von den Typen her ist das sauber definiert.

Beim `float`/`int`-Verhalten kann man eigentlich nur verlieren. Irgend wen überrascht das Verhalten immer, egal wie man es implementiert. Das betrifft auch Sprachen bei denen der Typ zum Namen und nicht zum Wert gehört, denn es kommt auch darauf an, in welchen Typen die Berechnung selbst ausgeführt wird. Dagegen helfen dann nur Sprachen bei denen man nicht die gleichen Operatoren für Gleitkommazahlen und ganze Zahlen verwenden kann, und beide Typen nicht ohne explizite Umwandlungen in einer Rechnung verwenden kann. *Das* finde ich aber ziemlich unhandlich und das ist sicher auch Anfängern nicht so leicht zu vermitteln warum einfache Sachen *so* umständlich gemacht werden müssen. Das finde ich bei OCaml zum Beispiel ätzend, dass man für Gleitkommazahlen ``+.``/``*.``/… verwenden muss.

Es werden in Python immer Objekte übergeben. Und zwar *immer* auf die *gleiche* Weise! Einen Unterschied zwischen Referenzen und Werten gibt es nicht. Die Sprache kennt gar keinen Datentyp „Referenz“. Also braucht man da auch keinen Unterschied lernen. Meistens entstehen die Verwirrungen bei Leuten die glauben es gäbe da unterschiedliche Arten Argumente zu übergeben und versuchen sich einen Reim darauf zu machen wie das wohl aussehen *könnte*.

[cofi]

Ich bin alter Pascalianer der ersten Stunde - bei "True == 1" bekomm' ich graue Haare. Ein Boolean ist kein Integer (das ist aber keine Python-Eigenart - sehr viele Sprachen behandeln False und Null gleichwertig).

Dass `issubclass(bool, int)` gilt ist IMO aber ein Implementierungsdetail[1] auf, dass man sich nicht stützen sollte.

Dass [], 0, usw zu False auswerten, kann einen Hin und Wieder beissen (mich erst gestern), aber im Allgemeinen fährt man damit besser und schreibt verständlicheren Code.

Die stillschweigende float/int-Conversion kann auch viele Stunden Fehlersuche bescheren - da wären dann vordeklarierte Typen eindeutig im Vorteil.

Von welchen Konversionen redest du? Dass man 1 + 0.1 und am Ende kommt eine FP-Zahl raus? Will man wirklich nur float + float rechnen können? Da sich `float` und `int` gleich verhalten sehe ich da auch kein Problem. Um die Erkenntnis, dass man mit FP nicht genau rechnen kann, kommt man leider nirgendwo herum.

Die Python-Regeln, wann Referenzen und wann Werte übergeben werden, sind mir bis heute nicht klar - und den meißten Anfängern wahrscheinlich auch nicht. Hier ist IMHO ein breites Betätigungsfeld für Seiteneffekte (und ganz schwer auffindbare Programm-Fehler).

Es werden immer nur Referenzen übergeben. Ausschliesslich. Einzig bei immutable Typen gibt es keinen Unterschied zwischen der Referenz und dem Wert.

Python hat einige Probleme und Schwachstellen und die darf man ruhig kritisieren, aber es sollten schon echte sein ...

[1] Ja die Sprachreferenz schreibt das vor und es ist kein klassisches Implementierungsdetail, aber ich hoffe es ist klar was ich meine.

[Leonidas]

Tom_H, du hast recht, ich denke ich muss dich jetzt wirklich verhauen. Aber nur verbal, also keine Angst

Ich kann deinen Punkt verstehen, mit statisch typisierten Sprachen, allerdings nicht die auswahl der Sprache. Denn C verarbeitet alles was wie ne Zahl aussieht, denn für C ist eigentlich alles ne Zahl und man kann beliebig im Speicher rumschreiben, und wunderbar Memory-Corruption basteln. Der typischste Fehler in C-Programmen ist, nunja, "Segmentation Fault", der meist passiert wenn man irgendwo irgendwas überschreibt bis es kracht. Nicht gerade Anfängerfreundlich. Und Pointer sind für viele Anfänger auch extrem schwer zu verstehen, ich hab den Sinn davon erst verstanden als ich angefangen habe x86-Assembler zu schreiben. Für ne sichere statisch typisierte Sprache würde ich eher zu Haskell, OCaml oder SML raten. Allerdings denke ich nicht, dass das allzuleicht für die meisten Anfänger sein wird. Auch wenn es schicke Sprachen sind, zweifellos.

Ich bin alter Pascalianer der ersten Stunde - bei "True == 1" bekomm' ich graue Haare. Ein Boolean ist kein Integer (das ist aber keine Python-Eigenart - sehr viele Sprachen behandeln False und Null gleichwertig).

Na, und dann empfiehlst du C, das als ANSI C erstens gar keine Booleans hat und als C99 diese quasi als aliase für 0 und 1 definiert sind. Interessant, aber nicht sehr konsequent von dir

Die stillschweigende float/int-Conversion kann auch viele Stunden Fehlersuche bescheren - da wären dann vordeklarierte Typen eindeutig im Vorteil.

Mag sein, allerdings aus eigener Erfahrung: passiert mir nie. Liegt daran, dass ich eigentlich nie Fälle hab wo Integer und Floats zusammengerechnet werden. Wenn dann sind die Integer konstanten und die Variablen Floats und es ist mir immer klar dass am Schluss Floats rauskommen.

Die Python-Regeln, wann Referenzen und wann Werte übergeben werden, sind mir bis heute nicht klar - und den meißten Anfängern wahrscheinlich auch nicht. Hier ist IMHO ein breites Betätigungsfeld für Seiteneffekte (und ganz schwer auffindbare Programm-Fehler).

Wie jemand schon sagte, die Regel ist einfach: "IMMER" Es werden immer Referenzen übergeben, nie die Objekte selbst. Und Referenzen sind keine Pointer.

Ich habe übrigens mit Fortran-77 auf Lochkarten an einer CDC-6500 angefangen.

Ohne dich jetzt diskreditieren zu wollen, das muss nicht viel heißen.

[snafu]

Dass `issubclass(bool, int)` gilt ist IMO aber ein Implementierungsdetail[1] auf, dass man sich nicht stützen sollte.

[...]

[1] Ja die Sprachreferenz schreibt das vor und es ist kein klassisches Implementierungsdetail, aber ich hoffe es ist klar was ich meine.

Nee, ist nicht wirklich klar. `int(True)` wird zu `1` und `int(False)` wird zu `0`. Man kann, wie schon gesagt wurde, sogar direkt ein `True == 1` machen. Wahrheitswerte werden also ziemlich offensichtlich ähnlich wie Nullen und Einsen behandelt (was ja jetzt nicht gerade eine total neue Erfindung von Python ist). Ich würde dies nicht als Implementierungsdetail ansehen, sondern als bewusst gewähltes Konzept. Und demzufolge macht es eben auch Sinn, dass Wahrheitswerte als eine spezielle Art von Integern eingestuft werden.

Als einziges Gegenargument würde mir nur die fehlende Typsicherheit einfallen, wenn "zufällig" irgendwo mal eine Eins rauskommt, obwohl ein Wahrheitswert erwartet wird. Aber mal ehrlich, das erscheint mir ziemlich konstruiert. Eigentlich weiß man, welchen Typ eine aufgerufene Funktion am Ende ausspuckt. Zudem: Wie oft vergleicht man denn explizit mittels `if result == True:`? Gängiger ist doch wohl ein `if result:` - und dies ist bekanntlich für alles wahr, was nicht Null oder "leer" ist. Also sowohl für `True`, als auch für Eins und für noch viele weitere tolle positive Zahlen.