Es gibt jetzt nich so viel was ich zu dem Thema beitragen kann, da BlackVivi und Trundle das meiste schon vorweg genommen haben. Aber vielleicht kann ich ja einen frischen Blickpunkt einwerfen.
numerix hat geschrieben:Ich wollte auch nicht grundsätzlich für den Einsatz von input() sprechen, aber es gibt so ein paar Statements die hier immer und immer wieder stereotyp wiederholt werden:
global ist böse
input ist böse
* import ist böse
Richtig, es gibt sogar noch mehr Stereotypen wie OOP ist der Retter aller Softwareprobleme, Java bietet durch das Typsystem inherent mehr Sicherheit, Linux ist das tollste OS für Nerds, Mac OS X das für Designer und Windows das für Idioten. Sowas nennt sich allgemeine Meinung aber wir sehen ja, dass in vielen Fällen das nicht so ist. Wir haben die Erfahrung das etwas differenzierter zu sehen und festzustellen dass einiges von den Stereotypen stimt und anderes hingegen nicht. Du kritisierst dass ``global``, ``input`` und ``*-Import`` auf papageiartige Weise von den Leuten verteufelt werden, weil andere es sagen. Das stimmt, jedoch muss man das etwas differenzierter, vielleicht auch in einem Kontext sehen. Wie wäre es mit der Sichtweise von jemandem der die Sprache kennt und einem Anfänger Tipps gibt auf die der Anfänger letztendlich auch von selbst durch Versuch und Irrtum auch gekommen wäre. Nur ist eben nicht immer die Zeit jedes mal wieder zu erklären
warum man etwas nicht so, sondern anders machen sollte. Daher finde ich es sinnvoll wenn so etwas auf einer Wiki-Seite zusammengefasst wird, die man zum Tipp linken kann, damit die Verteufelung von irgendetwas nicht dogmatisch wirkt sondern zeigt, dass da auch wahre technische Gründe dahinter stehen.
Das ``input()`` oft eigentlich fälschlicherweise mit ``raw_input()`` verwechselt wird hat Trundle ja schon erklärt. Für die Stern-Imports gilt, dass sie eigentlich für den Interaktiven Modus gedacht sind, damit man sich das Eintippen von Namespaces spart - mit einem ^D ist der Code aber auch wieder weg und muss von niemandem in Zukunft gelesen werden, dort ist so eine Vereinfachung durchaus mal praktisch.
numerix hat geschrieben:Gleiches gilt für global:
Wenn ein Pythonkurs nicht direkt über OOP einsteigt, dann sondern zunächst mal ganz ohne OOP grundlegende Datenstrukturen und Algorithmen behandelt, dann gibt es eben gelegentlich Fälle, wo eine Lösung mit global weit weniger aufwändig und transparenter ist als eine ohne.
Eigentlich nicht. Denn wenn man nicht OOP nutzt, wird man aber zumindest wohl Funktionen nutzen und die haben in Python wie auch in der Mathematik auch Rückgabewerte wie eben y = x². Die Idee, noch einen globalen Zustand einzuführen macht hingegen das Verständnis schwieriger, da Funktionen nicht mehr wie Blackboxen funktionieren wodurch die Zuordnung von Eingabe -> Funktion -> Ausgabe erschwert wird. Der globale Zustand gibt vielen Menschen ein warmes, flauschiges Gefühl der Geborgenheit (vielleicht weil Menschen an einen Globalen Zustand gewohnt sind), daher gibt es etwa das Singleton oder auch Borg-Pattern die eben globalen Zustand in ein Objekt verpacken und damit auch die OOP-Anhänger glücklich zu machen. Faktisch ist aber, dass globaler Zustand recht kompliziert zu handhaben ist, wie etwa Verwaltung des Zustandes über mehrere Threads beweist. (Hauptsächlich funktionale) Sprachen wie Erlang versuchen auch möglichst den globalen Zustand soweit es geht zu verbannen, weil er eben anfangs nett und weich ist aber später eher zu Verwirrung und Komplikationen führt.
numerix hat geschrieben:Und auch für den * import:
Wenn ich weiß, was ich tue, das heißt, ich weiß, was ich da importiere, spricht doch gar nichts dagegen, insbesondere bei Modulen, bei denen auf globaler Ebene nicht viel los ist und der Namensraum eben nicht "zugemüllt" wird.
Es geht weniger um das zumüllen, das ist nämlich, wie die die Namen mit den zwei Unterstrichen auch beweisen eher ein geringes Problem[1]. Das Problem ist die Übersicht. Manchmal fragt man sich wo ein bweisses Symbol/Name herkommt. Dies ist bei *-Imports eben nicht ganz ersichtlich. Vor allem wenn ich viele verschiedene Module importiere ist es praktisch mehrere Namespaces zu haben, aus denen man die Namen ziehen kann und in denen man dann auch Nachschauen kann.
[1] Die Scheme-Community hatte da unter anderem deswegen weil Scheme ein Lisp-1 mit einem gemeinsamen Namespace für Funktionen, Makros und Variablen ist, da ziemliche Probleme mit Name-Clashes, in denen Namen überschrieben worden sind. Dies führte unter anderem zu den hygienischen Makros, welche ein recht hochtrabender Begriff für ein gar nicht so kompliziertes Konzept ist, was eben sicherstellt dass es möglichst zu keinen Namenskollisionen kommt.