Diskussion:Python-Programmierung

Aus Wikibooks

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

[Bearbeiten] Achtung!

Arbeitet noch jemand an diesem Buch? Wenn ja, bitte hier melden, ansonsten beginne ich, das Buch alleine umzuarbeiten. --WStephan

Ja, ich. Hilfe ist jederzeit willkommen -- Dknauth 19:51, 30. Dec 2006 (GMT+1)
Ich würde auch mitarbeiten, habe aber wenig Erfahrung im Wicki. Grüsse Robert
vorstehender Beitrag stammt von RFr am 01:16, 2. Mai 2008 -- Schmidt2 18:18, 2. Mai 2008 (CEST)
An alle, die hier mitarbeiten wollen: Das Thema "Python" ist momentan im Umbruch, eine Zusammenfassung findet sich unter Benutzer:Schmidt2#Python. Das momentan aktivste Buch zum Thema ist Python unter Linux, daraus soll aber langfristig mehr werden. Wer mitarbeiten möchte, ist gerne willkommen, fehlende Wiki-Kenntnisse sind nicht schlimm. -- Schmidt2 18:18, 2. Mai 2008 (CEST)
Ich hätte potentiell Interesse mich dieses Buchs anzunehmen und in ein Buch über Python Grundlagen und Konzepte weiter zu entwickeln, womit es sich von der 00% fertig Python Referenz dadurch unterscheidet, dass es halt deutlich in die Breite geht und die Konzepte hinter einem Mechanismus erklärt. Zu 100% fertig Python unter Linux sollte es sich dahingehend unterscheiden, sich nicht auf eine Plattform zu konzentrieren und stattdessen neben C-Python auch Jython und Iron-Python zu erwähnen. -- Jrobln 16:35 11. März 2009 (CST)
Mein Tipp: Vergiss die vorhandenen Python-Bücher und fang ein neues an (außer du krempelst das hier komplett um). Ich würd heute kein Buch mehr anfangen, das Python 2.x erwähnt; schließlich gibt es schon eine 3.1-Alpha-Version und bis Dein Buch fertig wäre, ist 2.x Geschichte. Python unter Linux nimmt ausdrücklich Rücksicht auf heutige Debian-Nutzer, was ich für einen Fehler halte. Das führt zu dann zu solchen Texten wie "Ab Version 2.6 gibt es ... und ab Version 3.0 könnnen Sie stattdessen auch ...". Lieber riskieren, dass das fertige Buch seiner Zeit voraus ist, statt dass es veraltet ist. --84.131.174.212 18:11, 13. Mär. 2009 (CET)
Das habe ich mir auch schon überlegt, bin mir aber nicht sicher, dass eine totale Ausrichtung auf Python 3.X wirklich hilfreich ist. Ich befürchte nämlich, dass es noch Jahre dauern wird, bis Python 3000 aka Python 3 weite Verbreitung findet. Den Effekt kann man ja selbst bei 2.X beobachten. Wie viel Code verwendet new style classes (class foo(object)), Dekoratoren oder gar die meiner Meinung nach absolut genialen Context Manager (with)? Auf der anderen Seite gebe ich dir wiederum recht, ständig Texte in der Art »In Python 2.X funktioniert dies so..., in Python 3 so...« schreckt auch ab.

[Bearbeiten] Eigenständiges Buch

Warum befindet sich das Buch Python im Namensraum Programmierung? Es ist auf dem besten Weg ein eigenständiges Buch zu werden und sollte deshalb nach Python-Programmierung oä verschoben werden. Das würde auch das Einfügen von eigenen Seiten für Kapitel einfacher machen. --Stefan Kögl 09:15, 6. Sep 2004 (UTC)

Danke, aber ich möchte gerne noch ein bisschen am buch weiter arbeiten bevor es verschoben wird. Ich habe schon lange nicht mehr daran gearbeitet und sonst anscheinend auch niemand, deshalb halte ich die die für etwas verfrüht. --Jdaly 00:34, 11. Sep 2004 (UTC)

[Bearbeiten] Vorgehensweise

Auf die Gefahr als Spaßbremse dazustehen: Die Vorgehensweise, die die Seiten erkennen läßt, ist IMO grundfalsch. Zuerst muss man eine nahezu fertige Gliederung erarbeiten, bis runter zu einem Gliederungspunkt, der da z.B. heißt "for-Schleife". Grob kann man sich ja an Vorhandenem orientieren, wie z.B. http://www.ora.de/catalog/einpythonger/toc.html.

Dann, und erst dann, kann der Einzelne ein Kapitel/Thema bearbeiten, und zwar schon im ersten(!) Ansatz sollte das mit dem Anspruch auf Vollständigkeit geschehen. Auf sowas, wie das unter "Kontrollstrukturen" Stehende, kann man nicht aufbauen (Das bisschen Text oben ist zudem ziemlich hanebüchen).

Mir fehlt übrigens die Info, was für eine Art Buch (Referenz oder Lehrbuch, welche Zielgruppe etc.) überhaupt das Ziel ist. Kann ich aber auch übersehen haben.

Also, bevor da jemand unnötig Arbeit reinsteckt, sollte vielleicht dies und das geklärt werden. Jan

Im übrigen ist es, glaube ich, ein generelles Problem im WikiBooks... Das Wiki bietet zu wenig Hilfsmöglichkeiten eine Struktur aufzubauen und zu verwalten... Überall ist viel Handarbeit gefragt, aber das müßte eigentlich nicht sein... Oder täusche ich mich da?
Wo kann man dieses generelle Problem diskutieren???
Genrich 16:20, 5. Nov 2004 (UTC)
Ich habe vor mein Python buch als Lehrbuch für Anfänger zu schreiben, mit gelegentlichen Tipps für Programmierer. Ich sage mein buch da ich der hauptverantwortliche bin. Japh ist so freundlich und verbessert fiele meiner groben fahler. Ich habe nichts dagegen wen jemand mir Vorschläge machen würde oder helfen möchte aber es gibt anscheinend nicht fiele Python Programmierer auf der deutschen Wikibooks. --Jdaly 18:40, 6. Nov 2004 (UTC)
Macht es dann nicht ein Umbenennung nach "Python für Anfänger" o.ä. Genrich 19:13, 6. Nov 2004 (UTC)
Nein, Ich empfinde es nicht als notwendig das buch umzubenennen. Aber falls Später ein besseres, und vor allem einheitliches Nameschema für programmier Bücher eingeführt wird unterstütze ich das. --Jdaly 20:38, 6. Nov 2004 (UTC)

An alle, die hier Bücher Schreiben: Weiter so! Lasst euch nicht entmutigen von "Löschwütigen" Wikis! -- Ein Buch braucht Zeit. Es ist sehr einfach zu sagen, etwas soll gelöscht werden. Aber verbessern, das kann nicht jeder. Budget-Kürzungen vornehmen kann jeder. Aber das Geld richtig einsetzen, nicht. -- Die Vorgehensweise kann Top-Down oder Bottom-Up sein. Oder auch Basar-Mässig. Evt. wird sich erst mit der Zeit herauskristalisieren, was einem bei den Anfängen zu Python wichtig war. -- Ganz gut wäre natürlich ein Problem-Lösungs Ansatz. Also für jemand, der schon etwas Grundlagen weiss, der kann eine For-Schleife in Python an einem Beispiel erlernen. Also für Umsteiger und Anfänger wäre das super. Auch fand ich es gut, wenn nicht immer der gesamte Syntax und aller Sprachfeinheiten dargestellt werden. Diese kann ich auch sonst wo zu genüge finden. -- Sehr interessant wären echte, kleine, interssante Anwendungen (Problem-Lösungen). Wie z.B. ein Backup-Script. Anhand diesen Beispielen kann fast automatisch sehr viel trockene Theorie gelernt werden, ohne gross stur nur Syntax zu lernen.

Möglicher Aufbau:

 a) Das ist die Aufgabe
 b) So wirds in Python gelösst
 c) Und das ist die Erklärung dazu
 d) Evt. noch spezielles zur Syntax oder sonstige Feinheiten

Anspruch auf Vollständigkeit. Ist so wie so nicht möglich. Es gibt genug Bücher, die diesen Anspruch stellen und keines genügt diesem Anspruch. Dann müsste man den Source-Code zu Python abdrucken. Selbst dann wäre nicht genügt. -- Lieber ein paar einfache, kleine richtige Lösungen, auf die der Leser dann selber aufbauen kann, als ein reines theoretisches Pauken der kompleten Syntax. -- Fremdsprachen lernt man ja auch nicht, indem man zuerst den Dix auswändig lernt. 10 einfach Sätzchen sind mehr als die gesamte Syntax; wenns dann in der Praxis drauf an kommt.

[Bearbeiten] Formatierung für Beispiel Code

Hab mit die Python Seiten angeschaut... Was ich nicht gut finde, ist die Art wie Beispiel Code angezeigt wird. Ein Beispiel:

>>> test_int = 100
>>> type(test_int)
<type 'int'>
>>> test_long = 99999999999999999999999999999
>>> type(test_long)
<type 'long'>
>>> test_float = 6.0
>>> type(test_float)
<type 'float'>
>>> test_complex = 4.0 + 2.0j
>>> type(test_complex)
<type 'complex'>

Mit einem NonBreakingSpace kann man vielleicht einfach nur Leerzeilen einfügen (Wobei vielleicht gibt es da eine bessere Wiki-Like-Methode?) Hier mal meine Variante:

>>> test_int = 100
>>> type(test_int)
<type 'int'>
&nbsp
>>> test_long = 99999999999999999999999999999
>>> type(test_long)
<type 'long'>
&nbsp
>>> test_float = 6.0
>>> type(test_float)
<type 'float'>
&nbsp
>>> test_complex = 4.0 + 2.0j
>>> type(test_complex)
<type 'complex'>

Sind zwar mehr Zeilen, aber man kann es besser verstehen, was Ein- und Ausgaben sind, oder??? Aber was ist mit komplexeren Code-Beispielen??? Das Beispiel hier: Python-Programmierung:_Objekt-Orientiertes_Programmieren_und_Klassen finde ich nicht so doll... Die >>>-Zeichen stammen ja vom Python Kommandointerpreter. Bei echten Codeschnipseln, sind sie aber etwas fehlt am Platz, oder? Man könnte besser generell die Python-Ausgaben makieren und den Code so lassen wie es ist... Mann kann vielleicht besser mit dem pre-Tag arbeiten? Hier mal dazu ein Beispiel:

class Test:
    def __init__(self, name):
        print 'Hallo', name

test = Test("Markus")

Ergebniss:

Hallo Markus

JD 11:48, 11. Nov 2004 (UTC)

Ja der Code stammt alles von einer interaktiven Session, das ist Absicht. Ich kann die Code beispiele auseinander brechen um sie besser lesbar zu machen, damit habe ich keine Probleme. Ich habe keinen >>echten<< Code weil ich es recht idiotisch finde Jede menge Code hinzuzufügen wen ich kaum text habe. Andere haben sich über die Struktur meines Buches beschwert. Ich glaube ich sollte eine liste von dingen starten die ich am buch verbessern sollte. Ach ja, Hilfe ist immer willkommen. --Jdaly 13:47, 11. Nov 2004 (UTC)


Ich hab schon mal losgelegt: Python-Programmierung:_Kontrollstrukturen eigentlich wollte ich nur range() in xrange() ändern, da xrange für Schleifen generell besser ist... Dann habe ich auch noch die Überschriften geändert... Sorry... Ich denke nur, das es besser ist, wenn man im Inhaltsverzeichniss mehr auswählen kann, um gezielter einzusteigen...
Auch würde ich vorschlagen, das << Inhaltsverzeichniss auch zusätzlich oben ist... Das erleichtert ein wenig das Navigieren...
Ich hab die Sektionen Datentypen Operationen und Trickts und Tipps hinzugefügt...
JD 14:00, 11. Nov 2004 (UTC)

Wenn keiner was dagegen hat, kümmer ich mich um Python-Programmierung:_Objekt-Orientiertes_Programmieren_und_Klassen Dookie 00:40, 15. Nov 2004 (UTC)

Ich hab ganz sicher nicht's dagegen... Freud mich, das noch einer mitwirkt! JD 09:25, 15. Nov 2004 (UTC)
Was heißt denn 'kümmern'? Kann man damit rechnen, dass Du seitdem an den Inhalten arbeitest und Du sie in Kürze reinstellst? Mit dem Hinweis "--- wird fortgesetzt ---" blockierst Du ja faktisch das Kapitel für andere. Da wäre es schon hilfreich, in gewissen Abständen den Stand der Entwicklung zu erfahren. --Jan 19:00, 13. Dez 2004 (UTC)

[Bearbeiten] Verbesserungs-Vorschläge

  • Code als Interaktive Session Kenzeichen.
  • Interaktive Sessions Übersichtlicher machen.
  • Neue Kapitel Struktur.
  • Einführung
  • Einfache Datentypen
  • Strings
  • Lists
  • Tupel
  • Dictionary
  • Kontrollstrukturen
  • Funktionen
  • Objekt-Orientiertes Programmieren und Klassen
  • GUI Programmieren mit Tkinter
  • Tricks und Tipps
  • Listen
  • Mathe
  • Datenbank


Ich möchte die komplexeren Datentypen von den einfachen trennen. Beim kopieren wurden sie alle. Ich möchte auch das Kapitel Datentypen Operationen in die jeweiligen anderen Kapitel verschieben. --Jdaly 13:59, 11. Nov 2004 (UTC)

Was hälst du von der Aufteilung bei Python-Programmierung:_Datentypen_Operationen ... d.h. Strings, Lists, Tupel und Dictionary unter "Einfache Datentypen" packen... Oder meinst du damit was anderes??? s.oben JD 15:09, 11. Nov 2004 (UTC)
Ich wollte Stings, Lists, Tupels und Dictionaries je ein eigenes Kapitel widmen. Das sind komplexe Themen denen in eigentlich in jedem Python Buch seperate Kapitel gewidmet sind. --Jdaly 16:56, 11. Nov 2004 (UTC)
Ist die Frage ob man Tricks und Tipps nicht vielleicht direkt in Themen unterteilen soll... Jetzt gibt es zwar noch nicht viel dort, aber das kann sich ja ändern ;) Ich mach das mal oben die Themen rein, die es jetzt schon gibt JD 16:42, 11. Nov 2004 (UTC)
Jetzt verstehe ich gar nix mehr. Ich dachte, das Buch sollte eine Einführung in die Programmierung sein. So hatte ich Jdaly zumindest verstanden. Jetzt wird das eher eine Mischung aus "Learning Python", "Nutshell" und "Cookbook". Das artet doch total aus und wird unter Garantie Stückwerk bleiben. Jan
Ich finde Tipps und Tricks direkt in die Kapitel selber zu integrieren wäre wahrscheinlich eine gute Idee. Und da das Buch noch nicht besonders weit ist könnte man es wahrscheinlich spalten. In ein Anfänger Buch und ein Buch für Programmierer. Ich hab z.b. auch schon einen Tipp für C Programmierer hinzugefügt. Ich will dieses als Anfänger Buch lassen, würde aber auch gerne mit jemanden anderes an einem >>Für Programmierer<< Buch arbeiten. --Jdaly 17:04, 11. Nov 2004 (UTC)
Nur sollte man etwas gucken, wofür eigentlich Bedarf da ist. Ich denke, Bücher und Onlineinfos für Leute, die schon programmieren können, gibt es reichlich, sowohl Einführungen in die Sprache Python als auch Referenzen. Wozu Tricks und Tipps, wenn es das Python-Cookbook im Netz gibt? Für absolute Programmieranfänger (offensichtlich gibt es nicht wenige Schulen, die Python lehren) gibt's zwar auch dies und das, aber richtig überzeugend ist da eigentlich nix. Das wäre eine Marktlücke! Dabei sollte es gar nicht so sehr um Python gehen, sondern eher ums Programmieren im allgemeinen. Das hat auch den Vorteil, dass man Python nicht vollständig beschreiben muss. Dass es z.B. einen Datentyp complex gibt oder einen else-Zweig bei which- und for-Schleifen, könnte man dabei schlicht untern Tisch fallen lassen. Zu den C-Programmierer-Tipps: Warum ausgerechnet C? Ich denke, die meisten Umsteiger kommen eher von Mainstream-Sprachen wie PHP, VB oder Java. --Jan 18:10, 11. Nov 2004 (UTC)
Ich hab C als erste Sprache gelernt, das war ein Grund, der andere war das sich der tipp um das fehlen der switch und case keywords jedem C/C++/Java/C#/PHP und anderen Programmierern von C artigen sprachen auffallen würde. Die meisten Python Ressourcen im Internet die du angesprochen hast sind ja eigentlich in Englisch also glaube ich das ein Python Buch für Programmierer von nutzen sein könnte. Wo die Python Umsteiger heute her kommen weis ich nicht, aber an PHP, VB oder Java denke ich dort irgendwie nicht. Na ja ist ja nur meine Meinung. Wie ich schon gesagt habe, ich bin daran interessiert ein buch für Anfänger zu schreiben. Das wollte ich von anfange an. Ich möchte aber niemanden hindern den text hier zu nehmen und so weiter zu entwickeln das er für ein anderes Publikum zugeschnitten ist. Ich würde jeden solchen streben helfen wollen. --Jdaly 18:48, 11. Nov 2004 (UTC)
Nochmal konkret gefragt: Anfänger von was? Anfänger der Programmierung im Allgemeinen oder nur Python-Anfänger mit Erfahrungen in einer anderen Sprache? Entsprechend unterschiedlich müsste dann nämlich IMO die 'Ansprache' sein. Dem einen musst Du alles ab Adam und Eva erklären (Was ist eine Zeichenkette? Was passiert bei bla = 3.5 (Zuweisung, kein Vergleich)? etc.), dem anderen höchstens, was ein assoziatives Array (dict) ist. Aber letzter erwartet natürlich eine möglichst vollständige Beschreibung der Sprache. Ich fürchte nur, wenn man nicht klar die Zielgruppe benennt, wird das Werk ziemlich inhomogen. Naja, ich werd's erstmal beobachten und, wenn eine Entwicklung in eine Richtung erkennbar ist, vielleicht mitmachen. --Jan 19:26, 11. Nov 2004 (UTC)
Programmier Anfänger, ich dachte das war klar, wen nicht dann tut mir das leid. Jeder der eine andere Zielgruppe ansprechen will sollte den text in ein neues Buch auf Wikibooks kopieren. Klarer geht’s glaube ich nicht. :) --Jdaly 19:35, 11. Nov 2004 (UTC)
OK, mein Interesse liegt nicht unbedingt darin, ein Anfänger Buch zu schreiben... Ich möchte nur gern ein paar Dinge festhalten, die ich selber oft vergesse und nachlesen kann ;) Vielleicht sollte ich dann einfach ein zweites Buch eröffnen, sowas wie Python CodeSammlung oder so... Wobei ich alleine auch nicht so viel Energie Aufbringen kann, das es eine Runde Sache wird... Naja, was haltet ihr davon??? JD 21:28, 11. Nov 2004 (UTC)
Ich bin der Meinung dass wir das jetzige Buch solange weitermachen bis es wirklich problematisch wird mehrere Ideen unter einen Hut zu behalten. Außerdem nur weil es ein Anfänger Buch sein soll bedeutet nicht das es nicht auch komplett sein kann. --Jdaly 01:20, 12. Nov 2004 (UTC)

Zurück zu den Datentypen, ich will Strings, Tupels, Lists und Dictionaries separat von den anderen Datentypen behandeln. Entweder will ich ihnen je ein separates Kapitel widmen oder da sie ähnlich sind allen zusammen ein einziges Kapitel. Auf jeden fall will ich sie separat von den simpleren Datentypen behandeln. --Jdaly 19:51, 11. Nov 2004 (UTC)

Ich hab’s mir anders überlegt, Mittelerweilen bin ich doch für alle Datentypen in einem Kapitel. Es wird dann halt ein großes Kapitel. Ich möchte gerne Python-Programmierung:_Datentypen_Operationen mit Python-Programmierung:_Datentypen zusammenlegen da sie ja eigentlich zusammen gehören. Jedie was hältst du davon? Ich habe vor mich um Python-Programmierung:_Kontrollstrukturen zu kümmern. --Jdaly 12:30, 18. Nov 2004 (UTC)

Ich fände ein Buch gut, dass für Anfänger beginnt und dann immer anspruchsvoller wird und bei späteren Kapiteln (OO-Programmierung, GUI) wieder auf vorige Kapitel zurücklommt und diese näher erläutert, wenn nötig. Ich habe bis jetzt 2 Bücher gelesen und dennoch fallen mir immer wieder Bildungslücken auf... Hier fehlt mir noch Rekursion, ein teil der auszugsweise wichtige Module mit den wichtigsten Funktionen vorstellt (sys, cpickle, os, string) Input/Output (von Interaktion mit dem Benutzer bis dateien) als eigenes Kapitel und vielleicht sollte man auch try,except ein eigenes Kapitel widmen, schließlich ist das ein wichtiges Element von Python. Prinzipiell würde ich gerne an dem Buch mitarbeiten, vorher sollten wir aber die Struktur fertigstellen. mfg --WStephan 18:40, 20. Sep 2005 (UTC)

[Bearbeiten] Vereinheitlichung der Einrückungen

Die Einrückungen sollten unbedingt vereinheitlicht werden. Unter "Konstrollstrukturen" finden sich gleich drei unterschiedliche Varianten: nur ein Leerzeichen, ein Tab und 4 Leerzeichen (unter "break continue und else"). Letzteres finde ich eigentlich am besten. Leerzeichen (statt Tab) sind, glaube ich, auch die offizielle Empfehlung. Auch das "... " am Anfang der Fortsetzungszeilen in den "interaktiven Sessions" finde ich besser, da es zum einen Standard ist (nur IDLE macht es nicht so) und zum andern deutlich macht, dass man nochmal in einer leeren Zeilen <return> drücken muss, um den Block abzuschließen. --Jan 09:38, 12. Nov 2004 (UTC)

Ok, Ich hab' das mal umgesetzt (und mich dabei selten dämlich angestellt) --Jan 10:19, 14. Nov 2004 (UTC)

[Bearbeiten] Hintergrundinformationen: RAD-Sprache?

Ich bin etwas irritiert über die Einschätzung, dass Python als "RAD-Sprache" geeignet sei (zumal mir der Begriff nicht geläufig ist). Bei RAD geht es ja vorrangig um das visuelle "Zusammenklicken" von Anwendungen mittels RAD-Tools a la VB oder JBuilder: Dialoge entwerfen, Quellcode-Gerüste erstellen, Controls mit Funktionen verknüpfen, etc.

Bei VB würd ich vielleicht von einer "RAD-Sprache" sprechen, da sie AFAIK mit der visuellen IDE untrennbar verknüpft ist (im Gegensatz zu Java oder C#). Es gibt zwar wohl RAD-Tools (Boa Constructor?), die Python nutzen, aber besonders augenfällig finde ich die Eignung von Python dafür nicht. Prototyping dagegen würd ich viel eher als klassisches Aufgabenfeld für Python sehen. --Jan 12:28, 23. Nov 2004 (UTC)

VB kann ohne visuelle IDE programmiert werden. Auch kann dann auf sämtliche grafische Widgets der MFC zugegriffen werden... Dies ist also kein Kriterium. RAD hat eher weniger mit visueller Programmierung zu tun. Schnell mal googeln: http://whatis.techtarget.com/definition/0,,sid9_gci214246,00.html
Eher damit, dass OO Prinzipien und Modellbeschreibungen wie UML schnell abgebildet und überarbeitet werden können, wenn Business-Use-Cases es erfordern. Also Iterationsunterstützung, Refactoring, Re-use, Product-Cycling... Dass dies häufig an grafische Entwicklungsoberflächen angebunden stattfindet, lässt aber nur bedingt den Schluss zu, dass diese notwendiger Bestandteil ist. Schnelle Applikationsentwicklung, nicht schnelle Klick-Mich-Oberflächengestaltung! :-) --Oliver Merkel 14:14, 23. Nov 2004 (UTC)
RAD bedeutet nichts anderes als Rapid Application Development, grob übersetzt Schnelles Applikations Entwickeln. Und genau das kann man mit Python, nur weil in der Windows Welt RAD mit Visual Tools a la Visual Basic und Delphi in Verbindung gebracht wird verändert die Bedeutung von RAD nicht. --Jdaly 16:56, 23. Nov 2004 (UTC)
Ich hatte auch gegoogelt und fand zum Beispiel Folgendes: "Python bietet besonders gute Möglichkeiten zur schnellen Entwicklung umfangreicher Anwendungen, des sogenannten RAD." http://www.mediasonics.ch/i-pool/programming_python/ . Diese Definition von RAD halte ich für falsch. Es ist zwar lobenswert, dass man mit Python schnell Anwendungen programmieren kann (obwohl ich bei einer unfangreichen, GUI-lastigen Anwendung mit z.B. VC++/MFC deutlich schneller zum Ziel käme, als mit Python/TKinter), aber deswegen ist das IMO noch lange kein RAD. RAD bedingt die Anwendung bestimmter Methoden, die deutlich übers Programmieren/Kodieren hinausgehen (siehe auch Olivers Anmerkungen). Aber da bietet doch Python ansich rein gar nichts (oder?). RAD heißt zwar "schnelle Anwendungsentwicklung", aber der Umkehrschluss, "schnelle Anwendungsentwicklung" ist immer auch RAD, ist falsch. Eine "erweiterbare Auszeichnungssprache" muss ja auch nicht zwingend XML sein, auch wenn das die Übersetzung von XML ist.
Das haste jetzt schön gesagt. RAD ist etwas anderes als die Programmiersprache. Strenge OO-Sprachen sind eigentlich immer RAD-fähig, da die RAD-Definitionen ja aus dem Bereich der OO kommen und OO-Begriffe in den Buzz-Words Iterationsunterstützung, Refactoring, Re-use, Product-Cycling, UML, etc. verwendet werden.
RAD entsteht durch RAD-Tools, die die Sprache unterstützen. Komerziell kenne ich bei Python da Wing IDE, Black Adder, Python Works und natürlich Komodo... ich nehme mal an, dass da in letzter Zeit weitere RAD-Unterstützung für Python gewachsen ist.
RAD-fähig ist aber nicht RAD. Und ich glaube hier liegt der Punkt. Im Text ist das wohl als synonym anzunehmen, um selbst nicht als Korinthenkacker zu gelten... (bin aber einer... manchmal)...
Visuell in Python langsamer als VB/VC++/MFC??? Halte ich für ein Gerücht. Auch hierzu gibt es Tools und eine deutliche Mehrauswahl an unterstützten grafischen Oberflächen. TKinter ist halt als nice add-on mitgeliefert. Gibt aber noch deutlich mehr. QT, GTK, u.a.... Die oben genannten RAD-Tools unterstützen die von RAD unabhängige grafische Entwicklung teils (Black Adder mit QT, Python Works das mnitgelieferte TKinter). Auf der freien Schiene gibt es mindestens Glade für GTK-Entwicklungen auf der LibGlade. --Oliver Merkel 18:39, 23. Nov 2004 (UTC)
Nur weil menge B ein Subset von menge A ist heißt es nicht das beide identisch sind. Ob Python jetzt RAD genant werden darf ist ein unterschied in der Definierung die UNIX und Windows Programmierer benutzen. Wer zu seiner RAD Sprache noch ein RAD tool möchte kann Glade oder Boa Constructor benutzen. Aber zurück zum Thema, was für eine alternative Wort wall schlagen die RAD Gegner vor? --Jdaly 18:28, 23. Nov 2004 (UTC)
RAD-fähige Sprache (anstatt RAD-Sprache). Auch wenn ich nicht der angesprochene RAD-Gegner bin und hier nur vorbeigelesen habe. --Oliver Merkel 18:44, 23. Nov 2004 (UTC)
Es geht mir nicht um Wörter, sondern um Inhalte und da werden wir wohl keinen Konsens erzielen. Eine Programmiersprache, die keine RAD-Techniken aufweist, kann keine RAD-Sprache sein. Ist allerdings nur die Meinung eines Nicht-Informatikers. Naja, lassen wir den Text erstmal unverändert. --Jan 19:57, 23. Nov 2004 (UTC)

[Bearbeiten] Weiter

Könnte man nicht am Ende jedes Kapitels einen Weiter-Link einfügen? In der jetzigen Fassung muss man immer zurück zum Inhaltsverzeichnis, was auf die Dauer leicht nervig ist. --84.150.39.17 15:38, 4. Apr 2006 (UTC)

[Bearbeiten] Bibliotheken - urllib

Hallo!

Ich möchte gern ein kapitel zum Thema Bibliotheken - urllib schreiben. Gibt es irgendwas was ich beachten muss?

Gerne! Eine Gliederung vorab wäre nett. Dknauth 23:52, 11. Dec 2006 (GMT+1)

[Bearbeiten] Verwirrt

Es gibt:

  • Aufbau des Buches und
  • Momentaner Inhalt

wo soll man sich da beteiligen? Könnte mal jemand vom Autorenteam einen Teil löschen und wenigstens eine Gliederung hineinschreiben? Tandar 21:31, 6. Jan. 2008 (CET)

[Bearbeiten] Hinweis/Frage

So! Ich habe das Buch radikal umgegliedert. Im vorigen Zustand war das Buch einfach unhaltbar. Eine Mitarbeit anderer Autoren wurde durch die misteriöse Gliederung schon im Keim erstickt. Ich hoffe mir ist niemand böse falls ich den einen oder anderen Abschnitt gelöscht habe, aber so konnte es einfach nicht weiter gehen. Ich hoffe weiter, dass sich jetzt wieder Autoren finden die aktiv an de Buch arbeiten. HerrHagen --89.197.158.102 11:34, 11. Dez. 2008 (CET)

Jemand hat die Namen der Kapitel an die Wikibooks-Namenskonventionen angepasst, was ja auch in Ordnung ist. Allerdings sind dadurch viele alte, bereits angefangene Seiten nicht mehr erreichbar. Könnte jmd. der mehr Wissen über die Interna der Wikipedia hat, diese wieder über die Startseite erreichbar machen. DANKE --89.197.158.102 16:25, 11. Dez. 2008 (CET)
Welche Seiten vermisst du denn genau. Ich habe alle Seiten entsprechend der NK verschoben und auch die betroffenen und von Dir erstellten Unterseiten verschoben. -- ThePacker 09:27, 12. Dez. 2008 (CET)
Die Seiten die ich vermisse sind ganz gut daran zu erkennen, dass die Prozentanzeige hinter dem Abschnitt schon einen gewissen Fortschritt anzeigt, der entsprechende Link aber jetzt auf eine unagelegte Seite zeigt. Die Seiten hatten ursprünglich den selben namen wie der link, also z.B. os, time, etc. (Ich war davon ausgegangen das jedes Buch seinen eigenen Namenraum bekommt, und sowas deshalb unproblematisch ist). Unter welchen Namen find ich sie jetzt? Unter z.B. Python-Programmierung: time ist nichts zu finden. --89.197.188.100 10:32, 12. Dez. 2008 (CET)
"Time" habe ich nach "Python-Programmierung: Time" verschoben. es war als Link klein geschrieben, Jedoch können Namen in der obersten Hierarchie nicht mit kleinbuchstaben beginnen, weswegen ich den großgeschriebenen Titel "Time" verschoben habe. Lange Rede kurzer Sinn entweder man benennt "Phyton-Programmierung: Time" in "Phyton-Programmierung: time" um oder man korrigiert den Link und schreibt den ersten Buchstaben von Time groß. siehe hier -- ThePacker 11:37, 12. Dez. 2008 (CET)
Alles klar. Danke für die Erläuterung --89.197.156.75 15:35, 14. Dez. 2008 (CET)

[Bearbeiten] Warum Python? -> Textfreigabe?

Der Text ist offensichtlich von [1] übernommen. Ist das erlaubt? -- Tandar(D, B) 10:16, 3. Apr. 2009 (CEST)

Wenn es so wäre, dann nicht. Ich habe mir die Umgebung, insbesondere die Fußnoten angesehen, und glaube, dass der Text umgekehrt von hier übernommen wurde. Allerdings bin ich mit dem Text eh nicht sonderlich zufrieden und bin der Meinung, dass der geändert werden sollte. -- Jrobln - 13:55 3. März 2009 CEST
Von „http://de.wikibooks.org/wiki/Diskussion:Python-Programmierung“
Persönliche Werkzeuge