Ich versuch’s mal mit dem Threadthema: osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? Es ist eine einfache, leicht zu erlernende und leicht zu lesende, dabei aber umfassend ausgestattete, Sprache. Die Doku ist ausgezeichnet, alleine schon mit dem Tutorial auf deren Seite kann man ziemlich schnell ziemlich beeindruckende Sachen erstellen. Ziemlich gute IDEs, die dabei unterstützen, (z.B. Pycharm) sind verfügbar; es gibt aber auch ein shellartiges CLI mit Syntaxhighlighting und Autocomplete (ipython). Die meisten Editoren mit Fokus auf das Programmieren/Scripten bringen Funktionalität zur Nutzung von Python mit. Schnittstellen zu den großen UI-Toolkits (Gtk, Qt) sind vorhanden und ausgereift, so dass man auch mit wenig Aufwand grafische Programme schreiben kann. Schnittstellen zu den verbreiteten DBMS sind ebenfalls vorhanden, selbst ein integrierter Webserver fehlt nicht. Virtuelle Environments und ein integriertes Paketmanagementsystem mit schier grenzenloser Auswahl machen es extrem einfach, sich ein Setup für ein konkretes Projekt zusammenzustellen, ohne an der eigentlichen Installation rumpfuschen zu müssen. Der größte Posten des Preises für das alles, und viel mehr, ist der Ressourcenverbrauch und die geringe Ausführungsgeschwindigkeit. Um das zu kompensieren, kann man auf Schnittstellen zu C/C++ zurückgreifen, und zeitkritische oder auf andere Art rechenintensive Aufgaben etwa als Module dahin auszulagern, um vom eigentlichen Programm aus bequem darauf zuzugreifen. Auch gibt es Ansätze, mit denen sich Scripte kompilieren lassen. Typischerweise sind Pythonscripte gemessen an ihrer Funktionalität extrem kurz, und bleiben dabei lesbar (ich habe damals™ einen modularen IRC-Bot in weniger als fünfzig Zeilen implementiert, und konnte das nach mehreren Jahren immer noch einwandfrei selbst lesen) Bei all dem ist die Sprache weitgehend portabel, es ist also recht einfach, Software damit zu erstellen, die sowohl unter Linux, als auch unter Windows, als auch unter BSD, als auch unter MacOS läuft, als auch unter AIX, als auch unter den anderen unter https://www.python.org/download/other/ aufgeführten Systemen läuft. Aufgrund der oben genannten Eigenschaften (und vielen mehr) hat sich die Sprache weit verbreitet; es gibt eine riesige Community, in der man für eigentlich jedes Problem Unterstützung bekommen kann.
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag
#6492356:
> Was zu Python pro Monat an Materialen rauskommt,...
Unsereiner kriegt pro Monat so ungefähr einen Zentner an Werbung ins
Haus. Meinst du, das ist relevant - mal abgesehen von all den dafür
abgeholzten Wäldern?
W.S.
Beitrag #6492406 wurde von einem Moderator gelöscht.
19 Millionen können nicht irren. :-)) Google: "python indentation" Ungefähr 19.800.000 Ergebnisse (0,51 Sekunden) Yalu, dir widerspricht doch keiner grundlegend. Nur, was du sagst gilt auch für andere Scriptsprachen. Einschließlich der Nachteile. Ich ersetzte einfach Python mit Tcl und streich den Satz mit der Einrückung. Ersetze ihn aber mit den schwachsinnigen Kommentaren in Tcl. Das ist nämlich gleich dumm wie die Einrückung in Python. Ich sags nochmal, auch wenn es der User Sheeva wieder geflissentlich überliest: Es hängt im Wesentlichen davon ab, in welchen Umfeld du dich bewegst ob Scriptsprache X oder Y besser ist (oder als besser empfunden wird). Ein Vergleich mit C, C++, Java ist nicht zielführend, weil das compilierte Sprachen sind.
Nick M. schrieb: > schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag > #6492356: >> Außerdem machen die ihre Angebote gleich sehr attraktiv (wie bei Rust). >> Da gibt es eigene Webseite mit Tutorials, kostenlosen Büchern, >> kostenlosen IDE's und Plugins für für verschiedene Editoren // IDE's. Es >> werden STÄNDIG neue Bücher veröffentlicht. Neue Libs werden geschrieben >> / portiert. Und, und, und. > > Dürfte man das ganz vorsichtig als Hype bezeichnen? Das kann man jederzeit unter diesem Aspekt betrachten, müßte aber bei Python sehr schnell feststellen, daß das keineswegs ein Hype, sondern so eine Henne-Ei-Sache ist. Eine fast dreißig Jahre alte Programmiersprache, die sich im Laufe der letzten zehn, zwanzig Jahre zur beliebtesten, verbreitetsten und erwünschten Sprache zu bezeichnen, wird der Sache nicht gerecht, denn ein Hype (oder genauer: ein Medienhype) ist doch gemeinhin eine eher kurzfristige Angelegenheit und würde bedeuten, daß das solcherart "gehypte" ähnlich schnell wieder verschwände, wie es aufgetaucht ist. Python ist aber nicht schnell aufgetaucht, und seine Beliebtheit ist das Ergebnis von vielen Jahren einer stetigen Entwicklung, während der es sogar einige etablierte und eingesessene Platzhirsche wie Perl verdrängt, andere wie PHP stark unter Druck und sich gegen Wettbewerber wie Ruby durchgesetzt hat. Von einer Kurzfristigkeit, wie Du sie mit dem Begriff "Hype" insinuierst, ist jedoch im Zuge der Entstehung der aktuellen Situation -- wie gesagt: Python ist aktuell die beliebteste, verbreitetste und meistgewünschte General-Purpose-Skriptsprache der Welt -- also nichts zu sehen, und vom -- durch den Begriff "Hype" ebenfalls unterstellten -- baldigen Abflauen des Aufwärtstrends von Python ist bisher jedenfalls auch nichts zu erkennen. Tatsächlich ist es aber so, daß Python nunmal aktuell die beliebteste, verbreitetste und meistgewünschte General-Purpose-Skriptsprache der Welt ist und es im Moment auch keinen einzigen Hinweis darauf gibt, daß sich daran so bald etwas ändern wird. Diese Umstände haben Folgen, und zwar vor allem, daß immer mehr Entwickler sich für die Sprache interessieren und deswegen Bibliotheken dafür entwickeln. Andere schreiben Bücher darüber und bieten Kurse, Tutorien oder anderes an. Klar: wenn man sagen will, daß das nur die aktuelle Kuh sei, die durch das Dorf getrieben werde, bald wieder verschwände, und es deswegen unnötig sei, sich mit dem Thema zu beschäftigen: ja, dann kann man das als Hype bezeichnen, vorsichtig oder auch unvorsichtig, ganz nach Belieben. Aber wenn man das tut, wird man leider damit leben müssen, daß es dem, was einen Hype ausmacht, nicht ansatzweise entspricht, und das man deswegen Widerspruch erntet und eines Besseren belehrt wird. Du sagst, Python sei "just another scripting language", und das simmt natürlich auch. Wie jede andere Skriptsprache hat es gewisse Eigenschaften und Eigenarten, welche man gut -- für sich persönlich -- gerne oder schlecht finden kann. Aber das erklärt weder, warum Du es unbedingt zu einem Hype kleinreden willst, noch seinen grandiosen Erfolg, um den es -- langsam komme ich mir vor wie eine tibetanische Gebetsmühle -- in diesen Thread geht. Verstehst Du, was ein Thema ist? Außerdem ist Python ganz besonders stark in einem Bereich, den es tatsächlich schon lange gibt, der aber in den letzten Jahren besonders populär geworden ist und daher schon eher den Kriterien eines Hype entspricht. Nämlich der Verarbeitung, Analyse und Visualisierung von Massendaten, Stichworte: Big Data, Machine Learning, und Data Science. Und weil in den letzten Jahren immer mehr Anwendungsfälle den Weg in die praktische Anwendung gefunden haben und aktuell vielle Entwicklungen sowohl in der Wissenschaft, als auch in der Industrie und dem OSS-Umfeld stattfinden, gewinnt auch das damit eng verbundene Python weitere hohe Aufmerksamkeit, die ihm und seiner weiteren Verbreitung natürlich ebenfalls zuträglich ist. Du hast etwas weiter oben geschrieben, eine Sprache stünde oder fiele mit ihren Bibliotheken. Auch das ist richtig, und genau das einer der wichtigsten Gründe für den großen Erfolg von Python. Tatsächlich ist es umgekehrt aber genau diese große Vielfalt an leistungsfähigen, ausgereiften, aufeinander abgestimmten Bibliotheken (nebst weiteren Tools), die wesentlich zum enormen Erfolg von Python beitragen und zweifellos auch dafür sorgen, daß es kein Hype war, ist, oder wird. Und dabei ist es vor allem die Vielfalt von gut aufeinander abgestimmten Bibliotheken, die Pythons allergrößte Stärke darstellt. Vergleichbare Sprachen sind in der Regel nur in einer Domäne stark, PHP und Ruby zum Beispiel für die Webentwicklung. Es gibt zwar GUI-Frameworks und auch Bibliotheken für die Datenanalyse für diese beiden, aber nichts davon ist auch nur im Ansatz so ausgereift wie die verfügbaren Erweiterungen für Pyton. Perl ist zwar ein echter Allrounder, tut sich aber wie Ruby keinen Gefallen damit, Regular Expressions in den Sprachkern zu integrieren und Sonderzeichen zur Variablenauszeichnung zu benutzen, was die Lesbarkeit des Quellcode einschränkt. Die Antwort mancher Entwickler auf die verschiedenen Stärken und Schwächen ihrer Sprachen bringen manche Entwickler dazu, sich für jede Problemstellung und jeden Anwendungsfall eine eigene Sprache, deren eigene Infrastrukturen, und eine eigene IDE anzueignen. Klar, das kann man so machen. Mein Ansatz hingegen ist ein anderer: ich suche mir darum eine Sprache, die alles, was ich heute oder (soweit absehbar) in Zukunft machen möchte, gleichermaßen sehr gut beherrscht. Genauso wie ich einen Editor (oder einen Editor mit eingebauten Betriebssystem und eigener Programmiersprache, oder eine IDE) benutze, der mit dieser und mit allen anderen Sprachen gleichermaßen gut umgehen kann. Ich habe meine Wahl getroffen. Meine Skriptsprache hieß früher Perl, heute heißt sie Python, und mein Editor / IDE heißt GNU Emacs. Damit bin ich äußerst zufrieden, die Arbeit damit ist produktiv und macht mir erfreulicherweise zudem auch noch Spaß. Wer das nicht mag, soll eben was anderes nehmen. Muß ich das verstehen? Nein. Muß ich es akzeptieren? Aber ja, natürlich -- schon weil es mich nichts angeht. ;-)
Nick M. schrieb: > Sheeva P. schrieb: >> Nicht auch noch patzig werden, ja? > > Ja Glaubenskrieger! Python ist einfach die Sprache der Herrschenden. > Alle Anderen sind unterlegen. > Alahu Agbar! Schon lustig, wie angepiekt Du auf sachlichen Widerspruch reagierst. > Kann man aber überlesen, wenn man voller > Hass auf die Andersgläubigen ist. Da muß ich mich auf Dein geschätztes fachmännisches Urteil verlassen, damit kenne ich mich nicht aus und lege auch keinen Wert darauf, Erfahrung damit zu sammeln. > Ich häng mich derweil im vorauseilenden Gehorsam untertänigst auf. Laß mal, hinterher muß irgendein bedauernswerter Mensch die Sauerei wegmachen. Mir persönlich würde es schon reichen, wenn Du endlich einmal anfangen würdest, Dich wie ein Erwachsener zu benehmen und sachlich zu diskutieren, statt immer wieder mit diesen kindischen Ausfällen zu nerven in der Hoffnung, das würde mich beeindrucken.
Yalu X. schrieb: > [...] Wow, ein hervoragener Beitrag, der die Frage des TO vollständig beantwortet und es auch ansonsten perfekt auf den Punkt bringt. Danke!
Fast jeder kann Python schreiben, lesen quasi jeder, der man programmiert hat. Es ist extrem breit gefächerten, von einfachem Glue code über dicke Maschinen Lernen libs zu guter Visualisierung und GUI Anbindungen. Jeder Entwickler sollte ne Skriptsprache können imo, Python ist da einfach gut geeignet, weil man (im Gegenzug zur Standard bash zb) auch komplexer werdenden Probleme schön in den Griff bekommt. Habt immer die Praxis im Hinterhof! Fast alle ci/cd Umgebungen unterstützen Python, es gibt bereits fertige Module für Anbindungen zu gitlab, bitbucket, GitHub, egal was du willst. Auf Geschwindigkeit kommt es fast niemals an. PS, stark typisieren kann man mittlerweile per pypy auch. Für scientific computing gucke ich mir aber gerade Julia an. Auch sehr interessant :)
Sheeva P. schrieb: > Yalu X. schrieb: >> [...] > > Jack V. schrieb: >> [...] Wow, zwei hervorragende Beiträge, die die Frage des TO vollständig beantworten und es auch ansonsten perfekt auf den Punkt bringen. Danke!
Sheeva P. schrieb: > Du sagst, Python sei "just another scripting language", und das simmt > natürlich auch. Wie jede andere Skriptsprache hat es gewisse > Eigenschaften und Eigenarten, welche man gut -- für sich persönlich -- > gerne oder schlecht finden kann. Und jetzt? Hab ich jemals was anderes gesagt? > Aber das erklärt weder, warum Du es > unbedingt zu einem Hype kleinreden willst, Ich will es nicht kleinreden. Und verdammt nochmal LIES was ich geschrieben hab. Und zwar bis zum Ende des jeweiligen Beitrags. Und pick nicht den einzigen Satz dabei raus, der dir, oh du großer Evangelist der besten und einzigen Programmiersprache ... > langsam komme ich mir vor wie eine tibetanische > Gebetsmühle -- in diesen Thread geht. Keine Angst, du bist was du bist. Ein Leierkasten (muss nicht aus Tibet sein), der nur seine Meinung zulässt und die wahre Sprache gefunden hat. Stehst du auch immer an der gleichen Ecke und hältst den Wachturn der wahren Sprache Python hoch? Ich bin nur ein kleiner Sünder. Ja eine Hure sogar, die die Sprache verwendet die ihm gerade gefällt. Lass mich mal aufzählen: Basic, Pascal, Modula-2, Oberon, Eiffel, C, C++, ObjC, Fortran, Div. Assembler, Tcl, Perl, fehlen bestimmt noch paar. Das heißt nicht, dass ich die Sprachen noch kann! Ich bin kein Genie. > Verstehst Du, was ein Thema ist? Nö! Du? Warum regst du dich den (nach deinen Regeln) anhaltend völlig offtopic über andere Meinungen auf? > Ich habe meine Wahl getroffen. Andere auch. > Meine Skriptsprache hieß früher Perl, Meine auch. Aber vorher AWK. > heute heißt sie Python, Meine Tcl > und mein Editor / IDE heißt GNU Emacs. Je nachdem, aufm Mac eigentlich immer Sublime, auf Win oft Notepad++ oder halt der Editor von MPLAB X oder Quartus. Ich bin da nicht so verbohrt. Ist mir eher wurst, alle taugen was und manchmal nehm ich halt den ganz speziellen, der das als einziger kann. Ist wie mit den Sprachen oder den Prozessoren. Wenn mir was zu schwachsinnig ist, nehm ich was mit erträglichen Schwachsinn. Ist aber auch völlig egal, welchen Editor du verwendest, welch Scriptsprachen du nicht mehr magst und wie es dazu gekommen bist, dass du dich für etwas entschieden hast. Das gibt schon so viele Permutationen, dass es reichlich wenig werden die dir unabdingbar zujubeln werden. Der Rest deines Neuen Testaments ist wohl nicht lesenswert. Zumindest waren deine Vorherigen Posts schon zweifelhaft genug.
Beitrag #6492484 wurde von einem Moderator gelöscht.
Nick M. schrieb: > Yalu, dir widerspricht doch keiner grundlegend. Das würde ich auch keinem raten ;-) > Nur, was du sagst gilt auch für andere Scriptsprachen. Einschließlich > der Nachteile. Nur dass IMHO Python mehr Vorteile und weniger Nachteile in sich vereint als andere Programmiersprachen. Dennoch ist natürlich auch Python nicht perfekt, und was für den einen ein Vorteil ist, kann von einem anderen als Nachteil wahrgenommen werden. > Ich ersetzte einfach Python mit Tcl und streich den Satz mit der > Einrückung. Ersetze ihn aber mit den schwachsinnigen Kommentaren in Tcl. > Das ist nämlich gleich dumm wie die Einrückung in Python. Naja, zumindest die Syntax von Tcl ist im Vergleich zu Python ja schon ziemlich primitiv und unelegant. Sie erinnert mich stark an eine Shell-Sprache, mit ich ungern größere Softwareprojekte realisieren würde, auch wenn das prinzipiell natürlich möglich ist. Aber das ist natürlich bis zu einem gewissen Grad Geschmackssache. Weiter oben schrieb ja jemand, dass er auch Python nicht für große Projekte geeignet hält. > Ich sags nochmal, auch wenn es der User Sheeva wieder geflissentlich > überliest: Es hängt im Wesentlichen davon ab, in welchen Umfeld du dich > bewegst ob Scriptsprache X oder Y besser ist (oder als besser empfunden > wird). In diesem Punkt sind wir einer Meinung. Ich wollte mit einem obigen Beitrag Python auch nicht als die objektiv beste Programmiersprache propagieren, sondern die Vorteile aufzählen, die vermutlich der Grund für die ständig steigende Akzeptanz der Sprache sind. > Ein Vergleich mit C, C++, Java ist nicht zielführend, weil das > compilierte Sprachen sind. Warum nicht? Solange ein Programm tut, was es soll, und ausreichend flüssig läuft, interessiert es mich als Entwickler wenig und den Anwender überhaupt nicht, ob der Quellcode direkt interpretiert wird, vorher in einen Bytecode übersetzt wird, zur Laufzeit vielleicht noch einen JIT-Compiler durchläuft oder direkt in Native-Code übersetzt wird. Als es für Java noch keinen JIT-Compiler gab, wurde – genauso wie in Python – der Quellcode beim Entwickler in Bytecode kompiliert, der dann beim Anwender durch einen Bytecode-Interpreter ausgeführt wurde. Mittlerweile kann sowohl Java als auch Python in Nativ-Code überführt werden. Insofern ist die Kompilierbarkeit kein Kriterium für die Sinnhaftigkeit des Vergleichs zwischen zwei Programmiersprachen. Für mich besteht zwischen C++ und Python durchaus ein Konkurrenzkampf, der in meiner kleinen Welt nicht immer, aber immer öfter von Python gewonnen wird.
Yalu X. schrieb: > Warum nicht? Weil compilierte Sprachen vorher einen Check machen können. In Scriptsprachen kann man genialen Unsinn anstellen. Der entweder als Unsinn endet, oder tatsächlich genial ist. In Tcl sieht das bsp. so aus:
1 | proc Proc1 { num } { |
2 | puts "Proc $num" |
3 | }
|
4 | |
5 | proc Proc2 { num } { |
6 | puts "Proc $num" |
7 | }
|
8 | |
9 | for {set i 1} {$i < 3} {incr i} { |
10 | Proc$i $i |
11 | }
|
Die Schleife wird Proc1 und Proc2 aufrufen. Genauso kann man auch auf Variablen zugreifen. Und so ein typloser zusammengepappter Code lässt sich zur Compilezeit nicht überprüfen. Daher der Punkt in deiner Nachteils-Liste mit den Fehlern. Genau daher mag ich Skriptsprachen. Aber gleichzeitig kann man sich damit ganz elegant ins Bein schießen. Wenn sowas im Hause bleibt, ist das kein Problem. Warum das aber ausgeliefert ein übler Angriff gegen die eigene Firma sein kann versuch ich nicht nochmal zu erklären. Zu deinen anderen Punkten hab ich nicht wirklich was zu widersprechen.
Beitrag #6492505 wurde von einem Moderator gelöscht.
[Anm. d. Mod.: geloescht] Sheeva P. schrieb im Beitrag #6492505: > Trotzdem muß ich > widersprechen, denn: einer meiner wesentlichen Gründe für die Wahl von > Python war, daß es eben tatsächlich ein starker Allrounder ist. Ohne > Python würde ich Meß- und Massendaten wohl mit R verarbeiten, meine > Automatisierungen (immer noch) in Perl machen, FatClient-GUIs in C++ mit > Qt oder ebenfalls Perl, und Webapplikationen mit PHP oder Ruby (on > Rails) entwickeln. Hättest alles auch mit Tcl/Tk machen können. Das heißt aber weder das Eine, noch das Andere. Sind halt nur wieder ein Haufen Wörter von dir die letztendlich kein Argument sind. Weder für das Eine nach das Andere. Oder soll ich jetzt den Code für meinen LXI-Abfrage hier posten um irgendwas zu belegen. Wäre aber mit Tcl/Tk und hat hier nichts verloren. Hypothetisch: Mit den LXI-Daten bereite ich dann eine Datei für GNU-Plot auf und ruf dann Gnuplot auf. Also ist da auch gleich Automatisierung dabei. UI ist mit Tk. [Anm. d. Mod.: geloescht]
:
Bearbeitet durch Admin
Beitrag #6492530 wurde von einem Moderator gelöscht.
Sheeva P. schrieb im Beitrag #6492505:
> Aber zum Glück muß ich das nicht.
Eben. Darum braucht wir EINE Programmiersprache für alles.
Und Python ist dafür natürlich nicht geeigent ;-)
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag #6492532: > Und Python ist dafür natürlich nicht geeigent Deinem Nick nach codest du in Teuton (http://www.fiber-space.de/EasyExtend/doc/teuton/teuton.htm)? [scnr]
Beitrag #6492560 wurde von einem Moderator gelöscht.
Beitrag #6492563 wurde von einem Moderator gelöscht.
Yalu X. schrieb: > Naja, zumindest die Syntax von Tcl ist im Vergleich zu Python ja schon > ziemlich primitiv und unelegant. **SCHNIPP** > Aber das ist natürlich bis zu einem gewissen Grad Geschmackssache. Ja, was sag ich dazu? **Schulterzucken** Dir gefällt die Syntax nicht, ich finde sie anfangs verwirrend und daher eine Herausforderung. Ist schon ziemlich gaga was man in Tcl in einer Zeile schreiben kann. Das hat aber auch damit zu tun, ob man leserlichen code schreiben will oder nicht. Ist wie mit C und dem Obfuscated C-Contest. Was da rauskommt versteh ich nicht, will ich aber auch nicht verstehen. Ist mir zu mühsam. Andere finden es lustig. Auch OK. Ich finde sowas leserlich, so schreib ich Tcl
1 | foreach lineDict $::flawDrawLayout { |
2 | |
3 | if {[dict get $lineDict visible]} { |
4 | incr atY [dict get $lineDict height] |
5 | |
6 | set displayEngineToCall "" |
7 | append displayEngineToCall [dict get $lineDict engine] "::DataDisplay" |
8 | # Does that PB use and need engineSettings?
|
9 | if {[dict exists $lineDict engineSettings]} { |
10 | $displayEngineToCall $::canvasSignals $atY [dict get $lineDict dataSource] [dict get $lineDict engineSettings] |
11 | } else { |
12 | $displayEngineToCall $::canvasSignals $atY [dict get $lineDict dataSource] |
13 | }
|
14 | |
15 | incr atY 6 |
16 | }
|
17 | }
|
Natürlich ist das Geschmackssache! Darum geht es doch schon die ganze Zeit! Was fehlt ist die Anerkennung, dass es verschiedene Geschmäcker gibt.
[Anm. d. Mod: Abschnitt geloescht] > Sheeva P. schrieb im Beitrag #6492505: >> Trotzdem muß ich >> widersprechen, denn: einer meiner wesentlichen Gründe für die Wahl von >> Python war, daß es eben tatsächlich ein starker Allrounder ist. Ohne >> Python würde ich Meß- und Massendaten wohl mit R verarbeiten, meine >> Automatisierungen (immer noch) in Perl machen, FatClient-GUIs in C++ mit >> Qt oder ebenfalls Perl, und Webapplikationen mit PHP oder Ruby (on >> Rails) entwickeln. > > Hättest alles auch mit Tcl/Tk machen können. Das heißt aber weder das > Eine, noch das Andere. Bestimmt hätte ich das, aber auch genauso komfortabel? Wenn ich mir nur einmal die dankenswerterweise im Tcl-Wiki zusammengetragene Liste [1] von Tcl-Entsprechungen für Module anschaue, die Python bereits standardmäßig mitbringt, dann... äh... es mag sein, daß die Liste nicht sehr gut gepflegt ist, aber... Ich bin sicher, für fast alles, das es in Python gibt, findet man irgendwie auch eine entsprechende Bibliothek für Tcl. Aber die muß ich dann leider erst suchen, finden, und evaluieren. Oder ich muß mir eben selbst etwas schreiben... äh, ja, leider Not Invented Here, und dann muß ich's auch noch pflegen. > Oder soll ich jetzt den Code für meinen LXI-Abfrage hier posten um > irgendwas zu belegen. Du mußt hier gar nichts belegen. > Mit den LXI-Daten bereite ich dann eine Datei für GNU-Plot auf und ruf > dann Gnuplot auf. Also ist da auch gleich Automatisierung dabei. UI ist > mit Tk. Tjaaa, wie sage ich das jetzt, ohne daß Du es gleich wieder als Kreuzzug verstehen willst? Zu den schönen Eigenschaften von Python gehört, daß ich für so etwas keine externen Programme wie gnuplot brauche. Versteh' mich nicht falsch, ich kenne und mag gnuplot, aber... wie auch Tk und Tix sieht man seinen Ergebnissen leider auch das betagte Alter des Werkzeugs an. Mir persönlich wäre das egal, aber mein Chef, nunja, der ist bei so etwas leider ein bisschen komisch. Außerdem macht Gnuplot aus den Daten leider nur eine einzelne statische Grafik. Die Python-Library Pandas dagegen kann zwar auch statische Dateien generieren, aber sie kann mir auch ein interaktives Fenster öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche genauer anschauen kann. Oder sie erzeugt mir über Bokeh eine interaktive Darstellung meiner Daten fürs Web. Vielleicht magst Du mal unter [2] in einen anderen Thread schauen, wo ich mir den Spaß gemacht habe, ein kleines Skript zur Auswertung der Lesenswert-Zähler je Autor zu schreiben; da sind unten auch ein paar mit Pandas und Bokeh erzeugte interaktive Plots zu finden. [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules [2] Beitrag "Re: Linux wird nicht wirklich akzeptiert, woran liegt das ?"
:
Bearbeitet durch Admin
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag #6492532: > Sheeva P. schrieb im Beitrag #6492505: >> Aber zum Glück muß ich das nicht. > > Eben. Darum braucht wir EINE Programmiersprache für alles. > > Und Python ist dafür natürlich nicht geeigent ;-) Das stimmt, wir müssen alle sofort zu Assembler wechseln. ;-)
Nick, Sheeva, bitte haltet das Persönliche aus eurer Diskussion raus, oder beendet eure Diskussion hier.
Nick M. schrieb: > Rolf M. schrieb: >> Aber auch, dass andere sich daran nicht stören und diese doch sehr >> emotionalen Reaktionen nicht nachvollziehen können. > > Kein Problem für mich. Manche mögen dicke Frauen, ich nicht. > Aber emmotional ist daran nichts. Ja, du bleibst in dem Thread sachlicher als manch anderer, wobei das hier für mich schon emotional klingt: Nick M. schrieb: > dass dieser Einrückungsvorschriftsschwachsinn einige extrem nervt (mich > z.B.). Würdest du über dicke Frauen ähnlich sprechen, nur weil du die nicht bevorzugst? > Rolf M. schrieb: >>> Was aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen >>> Quelltext sind. >> >> Das ist dann wiederum das, was ich nicht verstehe. Warum stört man sich >> daran, dass die Sprache etwas erzwingt, das man doch sowieso macht? > > **Räusper** > Schalte bitte deinen Filter aus, wenn du die Gegenseite liest. Denn das > wurde oft genug auf unterschiedliche Art und Weise erklärt. Ich hab ja schon geschrieben, dass ich über ein "das macht man nicht. Whitespace setzt man so nicht ein, basta!" hinaus nicht viel an Argumenten finden konnte. Du bist da eher die Ausnahme mit dem Argument des zur Fehlersuche temporär eingefügten Code, und ich habe ja bestätigt, dass ich das auch als störend empfinde. Aber eben bei weitem nicht so sehr, dass ich das ganze Konzept deshalb zum "Einrückungsvorschriftsschwachsinn" degradieren würde. > Nick M. schrieb: >> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC >> oder Arm. > > Kapiert? Das sowieso. Das zeigt aber auch, dass es oft nicht um harte Fakten, sondern eher um Geschmackssache geht. Aber wenn jemand hier etwas als Argument aufführt, das für mich keinen Sinn ergibt oder keine Begründung hat, frage ich trotzdem nach.
Rolf M. schrieb: > Ja, du bleibst in dem Thread sachlicher als manch anderer, wobei das > hier für mich schon emotional klingt: > > Nick M. schrieb: >> dass dieser Einrückungsvorschriftsschwachsinn einige extrem nervt (mich >> z.B.). Ist halt für mich Schwachsinn. Genauso wie die Kommentare in meinem geliebten Tcl Schwachsinn sind. Ich bezeichne das gradraus als Schwachsinn. Weil da jemand einfach nicht nachgedacht hat. Die Deutschen sind doch bei den Amis dafür bekannt, dass sie deutlich sind. Gilt das jetzt nicht mehr? Das ist Schwachsinn für mich, daher ist aber nicht die komplette Sprache Schwachsinn. Das gilt für Tcl und für Phython. Aber nicht für Spin. :-)) Ich schreib es jetzt zum gefühlt 10ten Mal: Das endet nur in einem Sprachenkrieg. Und genau so ist es. Es gibt leider paar komplett Verbohrte die Python (oder sonst eine Sprache) als Religion ansehen. Ich bin nicht mit einer Sprache verheiratet. Es gibt paar Möglichkeiten. Die Firma verlangt Python von mir, ich gewöhn mich dran. Die Firma verlangt Python von mir, dann wechsle ich die Arbeit (hab ich schon mal gemacht, nicht wg. Python) Die Firma verlangt kein Python von mir, ich machs weil es mir gefällt. Die Firma verlangt kein Python von mir, was bin ich glücklich! Niemand verlangt Python von mir, darum mach ich Rubi. Niemand verlangt Python von mir, dann trink ich lieber Bier. Niemand verlangt Python von mir, mein Nachbar kanns, darum mach ich es auch. Niemand verlangt Python von mir, darum bin ich beim Ausprobieren bei Tcl hängen geblieben. Nieman verlangt Python von mir, aber ich find es Klasse! Ich mach C, weils mir Spaß macht. Und weils mir Spaß macht, such ich mir eine Arbeit die mir Spaß macht und wo ich das verwenden kann. Genauso wie mir mal NewtonScript sehr viel Spaß gemacht hat und ich auch eine Arbeit dafür gefunden hab. München-Starnberg kann man auch mit dem Rad fahren. Und durch den Wald auch mit dem Mountainbike. Dann ist der Spaß doppelt. Bis Steve Jobs den Newton von heute auf morgen den Hahn abgedreht hat und mein Spaß ein Ende hatte. Aber ich kauf immer noch Apple-Zeugs. Leute, das ist alles in Ordnung. Und genau desshalb sind diese Glaubenskriege hier alles andere als zielführend. Was von den Mods bestätigt werden kann. ;-)) (Danke für die Geduld)
Das ist ja soweit schön und gut, allerdings: Nick M. schrieb: > Weil da jemand einfach nicht nachgedacht hat. sollte heißen: weil da jemand zu anderen Schlüssen gekommen ist, als du. Sowas passiert, das ist kein Drama – aber denen dann unterstellen, dass sie nicht nachgedacht hätten, im Umkehrschluss also sich selbst als den Maßstab von allem darzustellen – das ist, mit Verlaub, für’n Arsch.
Rolf M. schrieb: >> Nick M. schrieb: >>> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC >>> oder Arm. >> >> Kapiert? > > Das sowieso. Das zeigt aber auch, dass es oft nicht um harte Fakten, > sondern eher um Geschmackssache geht. Äh, zum wiederholten Male: JA Ich finde xxx Schwachsinn. Lies bitte mein Posting davor bezüglich Tcl und Schwachsinn.
W.S. schrieb: > Hier geht es um das Fehlen der Blockmarkierungen und den Ersatz selbiger durch > das fehlerträchtige Maß von Einrückungen. Wie schon gesagt halte ich es für weniger fehlerträchtig, weil die Möglichkeit der Inkonsistenz zwischen Einrückung und Blockmarkierung wegfällt. Aber nun gut, da mag es andere Meinungen geben.
Jack V. schrieb: > sollte heißen: weil da jemand zu anderen Schlüssen gekommen ist, Tja, der Schöpfer der Sprache sieht das inzischen ja selbst schon nicht mehr als so genial an. Und wenn dich der Ausdruck "Schwachsinn" stört, dann nenn es halt "eine äussert ungeschickte und kurzsichtige Entscheidung die auf lange Sicht zu einem Umdenken führen wird" Ehrlich, für mich ist das halt so, denn wer Sprachen entwirft, kennt sicherlich auch andere Sprachen und deren Konzepte. Und wenn man mit einem recht einfachen und gängigen Konzept bricht, dann muss man dafür schon wirklich handfeste Argumente haben. Oder Starrköpfig sein. Oder Revanchist? Jetzt ehrlich! "Denen werde ich die Hammelbeine schon langziehen! Die werden die Einrückungen 4 Leerzeichen machen, weil ein Tab immer 4 Leerzeichen sind. Und damit die das kapieren, dürfen LZ und Tab nicht gemischt werden. Jawollllll! <harharhar>" Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere. Und darum bezeichne ich das als Schwachsinn. Anderen gefällts. Ich mag Mäuse nicht mal gebraten, die Katze frisst sie roh.
Rolf M. schrieb: > weil die > Möglichkeit der Inkonsistenz zwischen Einrückung und Blockmarkierung > wegfällt. Aber nun gut, da mag es andere Meinungen geben. Da ist auch nichts inkonsistent, das liegt nur in deinen (lobenswerten) ästhetischen Ansprüchen die dein (und erfreulicherweise auch mein) Editor gerne sklavisch auf Tastendruck umsetzt. Und jeder darf Einrücken und Zeileunumbrüche machen wie er mag und wann er mag. Juhuuuuu
Rolf M. schrieb: > Würdest du über dicke Frauen ähnlich sprechen, nur weil du die nicht > bevorzugst? Das würde der Mod dann völlig zu Recht löschen. ;-)
Bisher ausser Acht gelassene Besonderheiten, welche Python so beliebt machen: - es ist nicht C - es kommt ohne Präprozessor - es ist nicht Java - es ist nicht Perl - es ist gottlob nicht Tcl - es verunmöglicht sowas wie IOCCC - es vermeidet sowas wie MISRA - hat nicht so viele Dialekte wie K&R, ANSI, POSIX, C89, C99, ObjectiveC, C++, C#, usw. - die Transition von 2 zu 3 ist wohl nicht vollständig aber hochgradig automatisierbar dass Hilfsmittel dazu gleich mitgeliefert kommen - es hat den bewährten "pep" der offensichtlich effektiv ist (anders als ANSI oder wie das bei C/C++ heissen mag wo für alle Sonderlocken lobbyiert werden kann und letztlich alles, aber auch gar ALLES, mit rein kommt Hauptsache jedes Mitglied konnte eine Sonderlocke beitragen und keiner der alten Zöpfe wird gestrichen)
Yalu X. schrieb: >> Nur, was du sagst gilt auch für andere Scriptsprachen. >> Einschließlich der Nachteile. > > Nur dass IMHO Python mehr Vorteile und weniger Nachteile > in sich vereint als andere Programmiersprachen. Naja, leider scheint hier niemand ausreichend qualifiziert (oder motiviert), mal einen SACHLICHEN Vergleich z.B. zwischen Tcl und python vorzunehmen. Ich bin dafür nicht geeignet -- ich kenne nur Tcl. Interessieren würde es mich aber schon. >> Ich ersetzte einfach Python mit Tcl und streich den >> Satz mit der Einrückung. Ersetze ihn aber mit den >> schwachsinnigen Kommentaren in Tcl. Das ist nämlich >> gleich dumm wie die Einrückung in Python. > > Naja, zumindest die Syntax von Tcl ist im Vergleich zu > Python ja schon ziemlich primitiv und unelegant. Naja, das entbehrt nicht einer gewissen Komik, denn ein Großteil der verfügbaren Operationen und Operatoren ist 1:1 von C übernommen... (Diese Ähnlichkeit zu C halte ich übrigens für einen echten didaktischen Vorteil von Tcl.) > Sie erinnert mich stark an eine Shell-Sprache, Gut... die Substitutionsmechanismen sind ungewohnt. > mit ich ungern größere Softwareprojekte realisieren > würde, auch wenn das prinzipiell natürlich möglich > ist. Wieso? Wo ist da der Zusammenhang? Ich frage ernsthaft. Die Zuweisungen in der Form
1 | set a $b |
sind wegen der Präfixnotation und des notwendigen "$" erstmal murxig, aber das wird schnell zum Reflex. Der Hauptnachteil der eckigen Auswertungs-Klammern -- wie übrigens auch der geschweiften -- ist m.E., dass sie so beschissen auf der Tastatur zu erreichen sind. Ansonsten sehe ich in der Syntax nix, was größere Projekte verhindern würde. >> Ein Vergleich mit C, C++, Java ist nicht zielführend, >> weil das compilierte Sprachen sind. > > Warum nicht? Naja, das ist dasselbe, als wollte man eine konventionelle Dreh- oder Fräsmaschine mit einer CNC-Kiste vergleichen: CNC kann vieles, was konventionell nicht geht -- aber bei der konventionellen Maschine sehe ich viel leichter, was passiert, und kann viel leichter eingreifen. Für das Lernen und Probieren einfach besser. > Solange ein Programm tut, was es soll, [...] Nee -- interessant ist die Phase, in der das Programm noch NICHT das tut, was es soll -- vielleicht deshalb, weil ich Teile des Problems oder des Lösungsverfahrens noch nicht verstanden habe. In dieser Phase erfordern Scriptsprachen m.E. wesentlich weniger Verrenkungen.
Addendum (fast vergessen): - es darf jeder soviel einrücken wie er will solange er einrücken tut und dabei Konsistent bleibt Letztlich helfen aber "stalinistische" Tools wie pep8 einer parteidoktrinischen Gleichschaltung was Code-Style angeht, sodass SW-Engineering & -Metrik Tools auf Quellcodestufe so einfach möglich sind und gelingen dass gut und gerne auch fremde Libs mit moderatem Aufwand analysiert werden können, obendrein genausogut auch automatisch umgearbeitet sprich weiterentwickelt werden können. Bei Programmiersprachen die länger auf dieser Welt sind wurde das weniger gemacht resp. wurden damit trotz mehr Zeit weniger Fortschritte erzielt weil wohl irgendwas im Wege stand; ich mutmasse jetzt mal es sind die entweder ungünstigen Syntaxdefinitionen oder die allzu hohen/laxen Freiheitsgrade jener Syntaxen...
Nick M. schrieb: > Genauso wie die Kommentare in meinem geliebten > Tcl Schwachsinn sind. Ich bezeichne das gradraus > als Schwachsinn. Weil da jemand einfach nicht > nachgedacht hat. Ach Gott... das ist doch Kleinkram. Viel schlimmer finde ich, dass es für mehrfache Fallunterscheidungen offenbar mal eine case-Anweisung gab, die aber zu Gunsten einer C-typischen switch- Konstruktion abgeschafft wurde. So weit, so gut. Unabhängig davon gibt es natürlich eine break-Anweisung. Dumm nur, dass sich "switch" so verhält, wie man es von "case" in Pascal gewohnt ist (es gibt also keinen automatischen "fall-through"), so dass ein gewohnheitsmäßig angehängtes "break" am Ende eines Zweiges unerwartete Wirkung hat... :)
Sheeva P. schrieb: > aber sie kann mir auch ein interaktives Fenster > öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche > genauer anschauen kann. Ja toll. Und ich hab einen interaktiven Editor für harmonische Nockenwellen mit Flachstößeln in Tkl/Tk geschrieben. Wo du jeden Parameter angeben kannst und dann dazu die Erhebungskurve, die Ventilgeschwindigkeit und die Beschleunigung jeweils über °KW bei gegebener Drehzahl graphisch dargestellt wird. Der ganze Spaß wird dann als G-Code ausgegeben für die Fräsmaschine mit einer 4. Achse. Ist auch langweilig, ich weiß. Ist auch kein Argument für Tcl, ich weiß. Gilt aber genauso für Python, ich weiß. Möglicherweise weißt du nicht, dass man das "Schw*nzvergleich" nennt, ich weiß es. Sheeva P. schrieb: > [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules Hast sicherlich ganz aus Versehen das da in deinem Link übersehen: A cautionary note - the Tcl column is empty not because the functionality is unavailable, but because no one finds it worthwhile to complete the table! Also note that some of these modules make no sense for Tcl.
> Naja, leider scheint hier niemand ausreichend qualifiziert > (oder motiviert), mal einen SACHLICHEN Vergleich z.B. > zwischen Tcl und python vorzunehmen. Ich bin dafür nicht > geeignet -- ich kenne nur Tcl. Interessieren würde es > mich aber schon. MEIN ganz persönlicher Abtörner bei Tcl/Tk (das war so ca.'95) offenbarte sich als ich wiederholt /Boilerplate/scschreiben musste der Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ Einzelelement?/ Kein Element? Sowas ist mir bei Python (damals so vor 1.5 WIMRE) nie untergekommen: das abwickeln von "[]"/"[EinzelElem]"/"[Elem1, Elem2, ...]" lässt sich schön homogen mit "for el in lst"/Iterator/list-comprehnsion/list-sliceing... hinschreiben ohne dass Fallunterscheidung nötig ist. Ok, die Errinnerung an damals ist jetzt bröckelig, ich war "jung" und hatte kein Tcl-Guru in Reichweite um das gute Handwerk abzugucken. Vielleicht war(en) es auch nur bestimmte Lib-Funktionen (irgend was mit Verzeichnisse/Dateien listen) welche blöd implementiert waren... ich weiss es nicht mehr so genau ausser die Lehre welche ich mir merkte: "SOWAS will ich nicht mehr anfassen". Wie Tcl heute ist hab ich mir nicht angeguckt, ev. hat es auch Evolution genossen...
Programmiersprachentheaterintendant schrieb: > Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von > Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ > Einzelelement?/ Kein Element?
1 | foreach element $elements { |
Hast du das gesucht? ;-)
Nick M. schrieb: > Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere. Es hindert dich überhaupt keiner daran, das auch bei Python so zu handhaben. Hab ich damals™, zu Zeiten der hübschen 4:3-Monitore mit verhältnismäßig geringer Auflösung, genau so gemacht, damit’s im Editor nicht zu weit nach rechts abgehauen ist, wenn es mal etwas verschachtelter wurde. Dass es konsistent sein sollte, dürfte sich eigentlich von selbst verstehen. Zumindest würde ich ansonsten gleiches Recht für alle fordern, und in anderen Sprachen auch Klammern wild mischen dürfen:
1 | int main () [ |
2 | … |
3 | } |
OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner Klammerorgien gehasst, wenn ich damit mal zu tun hatte (und zwar noch, bevor ich Python überhaupt kannte). Ist mir aber nicht in den Sinn gekommen, es deswegen „Schwachsinn“ zu nennen und zu behaupten, ich alleine wüsste, wie man es zu machen hätte …
:
Bearbeitet durch User
Rolf M. schrieb: > Ich hab ja schon geschrieben, dass ich über ein "das macht man nicht. > Whitespace setzt man so nicht ein, basta!" hinaus nicht viel an > Argumenten finden konnte. Es gab auch einige "ich mag das einfach nicht"... ;-) > Du bist da eher die Ausnahme mit dem Argument > des zur Fehlersuche temporär eingefügten Code, und ich habe ja > bestätigt, dass ich das auch als störend empfinde. Wie müßte ich mir das mit diesem temporär eingefügten Code denn in der Praxis vorstellen? Vielleicht habt Ihr da ja andere, womöglich bessere Ideen als ich. Unterhalb der Blockebene ist mein Code üblicherweise in kleine, zusammenhängende Einheiten strukturiert. Weil das jetzt sehr abstrakt klingt, möchte ich ein kurzes Beispiel aus dem Skript geben, mit dem ich die oben verlinkte Statistik erzeuge. Da ist mir tatsächlich heute ein kleiner Fehler aufgefallen, in folgendem Code:
1 | plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() |
2 | DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', |
3 | 'Freitag', 'Samstag', 'Sonntag'] |
4 | plot_dayofweek.index = DAYS # Fehler hier! |
Es folgt noch eine Zeile, aber dies ist der Code, der den mittleren Plot in der Thread-Statistik erzeugt. Oberhalb und unterhalb des Code befindet sich jeweils eine Leerzeile, um ihn von dem Code abzusetzen, der die Plots für Stunden und Datum baut. Nun, jedenfalls warf der betreffende Code eine Exception und brach die Ausführung in der Zeile "# Fehler hier!" ab. Also habe ich meinen Code editiert:
1 | plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() |
2 | DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', |
3 | 'Freitag', 'Samstag', 'Sonntag'] |
4 | print('before error:', plot_dayofweek) # Guckstu...
|
5 | plot_dayofweek.index = DAYS # Fehler hier! |
Dabei kam heraus -- ich hatte das Skript auf diesen Thread hier angewendet -- daß dieser Thread erst seit Dienstag läuft, der Dataframe also nur vier Tage beinhaltet und daher meckert, wenn ich ihm meinen siebenstelligen Index mit allen Wochentagen zuweisen will. Jetzt sieht mein Code so aus und funktioniert wieder perfekt:
1 | plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() |
2 | DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', |
3 | 'Freitag', 'Samstag', 'Sonntag'] |
4 | days = list() |
5 | for i in plot_dayofweek.index: days.append(DAYS[i]) |
6 | plot_dayofweek.index = days |
7 | plot_dayofweek = plot_dayofweek.plot_bokeh( |
8 | kind='bar', show_figure=False, xlabel='Wochentag', |
9 | ylabel='Anzahl Beiträge', legend=None, colormap=['orange']) |
Da mein Code ansonsten keinerlei print()-Statements enthält, sondern natürlich das logging-Framework aus Pythons Standardbibliothek benutzt, wäre der Debug-Code (mit "# Wooot?" gekennzeichnet) auch schnell wiedergefunden und entfernt, ansonsten hätte ich ihn mit drei Leerzeilen abgesetzt oder mit Kommentaren gerahmt. Nebenbei hat mich das an einen anderen Punkt erinnert, der sicherlich auch zur großen Beliebtheit von Python beiträgt: die einfachen Möglichkeiten zum Debugging. Angefangen damit, daß ich Code einfach auskommentieren kann -- sowohl als einzelne Zeile mit dem auch aus anderen Sprachen bekannten Hashpound, als auch einfach als Multiline-String mit """ oder ''' an Anfang und Ende. Außerdem läßt sich so ziemlich jedes Python-Objekt in einen String wandeln und auf der Kommandozeile oder in eine Logdatei ausgeben. Wenn das noch nicht reicht, kann ich mit type() den Typ meines Objekts erfragen, mit dir() alle Symbole im aktuellen Scope ausgeben oder mit dir(obj) alle Methoden- und Eigenschaftsnamen im Scope des übergebenen Objekts. Mit vars() kann ich das die lokalen Variablen ausgeben (genau wie mit locals()), oder mit vars(obj) das interne _dict_ des übergebenen Objekts. Eine andere sehr interessante Eigenschaft sind die Docstrings -- und die manchmal sehr nützliche Möglichkeit, über die Eigenschaft _doc_ direkt aus dem Code meines Programms heraus auf die eigene Dokumentation oder die anderer Objekte zuzugreifen. Für die Docstrings gibt es noch eine andere, durchaus nützliche Verwendung: die Doctests. Damit kann ich für simple Klassen und Funktionen ganz einfach eine Art Unittest erstellen: ich lade das Teil in eine interaktive Python-Shell, lade meine Funktionen und Klassen, führe sie aus und speichere das in einem Docstring. Dazu ein kleines Beispiel:
1 | #!/usr/bin/env python
|
2 | """
|
3 | just some simple demo
|
4 | |
5 | >>> from b import * |
6 | >>> d = Dings(90) |
7 | >>> what('d', d) |
8 | +++ inspecting "d" begin |
9 | docstring: just some Dings class |
10 | type(): <class 'b.Dings'> |
11 | dir(): ['__class__', '__delattr__', '__dict__', '__dir__' |
12 | vars(): {'a': 10, 'b': 20, 'c': 90} |
13 | --- inspecting "d" |
14 | >>>
|
15 | """
|
16 | |
17 | |
18 | def what(name, obj, linelen=50, indent=4):
|
19 | """inspects an named object obj""" |
20 | print('+++ inspecting "{}" begin'.format(name)) |
21 | print(' '*indent + 'docstring:', obj.__doc__) |
22 | print(' '*indent + 'type(): {}'.format(type(obj))) |
23 | print(' '*indent + 'dir():', str(dir(obj))[:linelen]) |
24 | try: print(' '*indent + 'vars():', str(vars(obj))[:linelen]) |
25 | except: pass
|
26 | print('--- inspecting "{}"'.format(name)) |
27 | |
28 | |
29 | class Dings(object):
|
30 | """just some Dings class""" |
31 | def __init__(self, c):
|
32 | self.a = 10
|
33 | self.b = 20
|
34 | self.c = c
|
35 | |
36 |
|
37 | if __name__ == '__main__': |
38 | d = Dings(30)
|
39 | what('d', d) |
Wenn ich das mit "python -m doctest -v b.by" ausführe, ist die Ausgabe wie folgt:
1 | Trying: |
2 | from b import * |
3 | Expecting nothing |
4 | ok |
5 | Trying: |
6 | d = Dings(90) |
7 | Expecting nothing |
8 | ok |
9 | Trying: |
10 | what('d', d)
|
11 | Expecting: |
12 | +++ inspecting "d" begin |
13 | docstring: just some Dings class |
14 | type(): <class 'b.Dings'> |
15 | dir(): ['__class__', '__delattr__', '__dict__', '__dir__' |
16 | vars(): {'a': 10, 'b': 20, 'c': 90}
|
17 | --- inspecting "d" |
18 | ok |
19 | 3 items had no tests: |
20 | b.Dings |
21 | b.Dings.__init__ |
22 | b.what |
23 | 1 items passed all tests: |
24 | 3 tests in b |
25 | 3 tests in 4 items. |
26 | 3 passed and 0 failed. |
27 | Test passed. |
Diese "Unittests" sind zwar sehr einfach, und für umfangreicheren Code würde ich natürlich ein entsprechendes Framework wie das im Standardumfang von Python befindliche unittest, oder auch etwas externes wie PyTest oder Testify nehmen. Jedoch... für einfache Anwendungsfälle ist doctest schon sehr brauchbar, nicht zuletzt auch, weil der Code in den Kommentaren gleichzeitig auch beispielhaft dokumentiert, wie die einzelnen Objekte genau benutzt werden.
Nick M. schrieb: > Programmiersprachentheaterintendant schrieb: >> Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von >> Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ >> Einzelelement?/ Kein Element? > >
1 | > foreach element $elements { |
2 | >
|
> > Hast du das gesucht? ;-) Ich verstehe zwar dein ";-)" und auch wenn meine Errinnerungen nicht mehr so präzise sind, bin ich doch zuversichtlich dass ich das gefunden hatte. Meine Beschreibung sagt aber dass die Fallunterscheidung nötig war BEVOR das zur anwendung kommen kann. Ich versuche zu rekonstruieren: schreib in deinem Codeabschnitt an Stelle von "$elements" einen Funktionsaufruf hin - geht das dann immernoch? Egal ob die Funktion eine mehrelementige Liste oder ein Einzelelement oder NOPE zurückgibt?
Nick M. schrieb: > Oder Revanchist? Jetzt ehrlich! > "Denen werde ich die Hammelbeine schon langziehen! Die werden die > Einrückungen 4 Leerzeichen machen, weil ein Tab immer 4 Leerzeichen > sind. Und damit die das kapieren, dürfen LZ und Tab nicht gemischt > werden. Jawollllll! <harharhar>" > > Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere. Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt. Es muß nur konsistent sein. Ich hab früher übrigens auch zwei Leerzeichen benutzt, bis ich irgendwann zu faul wurde, den Editor umzukonfigurieren und meine Mitarbeiter und Kollegen damit zu stressen.
Jack V. schrieb: > Zumindest würde ich ansonsten gleiches > Recht für alle fordern, und in anderen Sprachen auch Klammern wild > mischen dürfen: Huch! Hab ich das gefordert? Dann muss ich mich entschuldigen! Das wäre ja Schwachsinn[tm]. Jack V. schrieb: > OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner > Klammerorgien gehasst, OK, ich hab vorher ObjC gelernt, da gewöhnt man sich an eckige Klammern gaaaanz schnell. Und dass bei jedem Funktionsaufruf der parameter auch mit Namen genannt werden muss (wie bei Verilog wenn man die Reihenfolge ändert). Und irgendwie muss man da immer von innen nach aussen lesen, wobei innen eher rechts steht. Ist halt so, es war meine Lieblingssprache bis jetzt. Aber sublime macht aus einem "proc<tab> ein: proc name {args} \ { } Darum liebe ich Orgien. ;-) Aber zugegeben, mit diesen eckigen und geschweiften Klammern oder die "" und was die machen oder nicht, das ist nicht ganz so einfach. Aber das ist halt Syntax die festlegt wann Ausdrücke berechnet werden. Und das find ich verdammt cool. Aber eigentlich geht es um Python, nicht dass noch einer vom Glauben abfällt. ;-)
Egon D. schrieb: > Yalu X. schrieb: >> Nur dass IMHO Python mehr Vorteile und weniger Nachteile >> in sich vereint als andere Programmiersprachen. > > Naja, leider scheint hier niemand ausreichend qualifiziert > (oder motiviert), mal einen SACHLICHEN Vergleich z.B. > zwischen Tcl und python vorzunehmen. Ich bin dafür nicht > geeignet -- ich kenne nur Tcl. Interessieren würde es > mich aber schon. Vielleicht ließe sich das ja als eine Art "Gemeinschaftsarbeit" in einem eigenen Thread machen? Immerhin gibt es hier in diesem Thread schon doppelt so viele Tcl-Freunde, als mir bisher je persönlich begegnet sind. > Naja, das entbehrt nicht einer gewissen Komik, denn ein > Großteil der verfügbaren Operationen und Operatoren ist > 1:1 von C übernommen... > > (Diese Ähnlichkeit zu C halte ich übrigens für einen > echten didaktischen Vorteil von Tcl.) Naja, die Syntax von C als hochentwickelt oder gar eleganz zu bezeichnen, erscheint mir allerdings ziemlich... mutig. > Die Zuweisungen in der Form >
1 | > set a $b |
2 | > |
> sind wegen der Präfixnotation und des notwendigen "$" > erstmal murxig, aber das wird schnell zum Reflex. Immerhin wurde meines Wissens auf echte polnische Notation verzichtet -- und, vor allem, auf Klammern! >> Solange ein Programm tut, was es soll, [...] > > Nee -- interessant ist die Phase, in der das Programm noch > NICHT das tut, was es soll -- vielleicht deshalb, weil ich > Teile des Problems oder des Lösungsverfahrens noch nicht > verstanden habe. In dieser Phase erfordern Scriptsprachen > m.E. wesentlich weniger Verrenkungen. Vor allem sind sie meistens kompakter, man muß sich bei der Fehlersuche also durch wesentlich weniger Code fräsen. Und Skriptsprachen bieten, wenngleich in ziemlich unterschiedlichem Ausmaß, oft viel bessere Möglichkeiten zur Introspektion.
Jack V. schrieb: > OT: weil du TCL ins Spiel gebracht hast: ich hab das > wegen seiner Klammerorgien gehasst, Das ist legitim (auch wenn es mir nicht so geht). > Ist mir aber nicht in den Sinn gekommen, es deswegen > „Schwachsinn“ zu nennen [...] Kannst Du ja bei Bedarf noch nachholen... :) > und zu behaupten, ich alleine wüsste, wie man es zu > machen hätte … Nee, umgekehrt: Es geht nur darum, wie man es garantiert NICHT machen soll. Siehe mein Beispiel mit "switch": Tcl ahmt in vielen Dingen C nach (und das ist auch gut so), gerade was die Steuerstruktur betrifft. Wie man da auf die Idee kommen kann, eine Steueranweisung zu schaffen, die GENAUSO aussieht wie die Entsprechung in C, sich aber ANDERS verhält -- das wird mir ewig ein Rätsel bleiben. Das ist doch geradezu eine Einladung für idiotische Irrtümer!
Sheeva P. schrieb: > Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die > Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt. Nur nicht Tabs und LZ mischen, das hab ich schon verstanden. Ist ja auch einleuchtend, denn so darf jeder das machen was einer festlegt. Wobei es jeder so machen kann, wie er mag, solang sich die Anderen daran halten. 8-/
Nick M. schrieb: > Sheeva P. schrieb: >> aber sie kann mir auch ein interaktives Fenster >> öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche >> genauer anschauen kann. > > Ja toll. Und ich hab einen interaktiven Editor für harmonische > Nockenwellen mit Flachstößeln in Tkl/Tk geschrieben. Schick, aber Du hattest ein Beispiel genannt und ich erklärt, daß es in Python für dieses Beispiel deutlich bessere (und hübschere) Möglichkeiten gibt, und zwar ohne dazu auf externe Software zugreifen zu müssen. > Möglicherweise weißt du nicht, dass man das "Schw*nzvergleich" nennt, > ich weiß es. Ach... Du kannst es einfach nicht lassen, nein? > Sheeva P. schrieb: >> [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules > > Hast sicherlich ganz aus Versehen das da in deinem Link übersehen: Nein. Im Gegenteil hatte ich sogar ausdrücklich dazu geschrieben, daß diese Liste womöglich unvollständig sein könnte.
Nick M. schrieb: > Programmiersprachentheaterintendant schrieb: >> Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von >> Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ >> Einzelelement?/ Kein Element? > >
1 | > foreach element $elements { |
2 | >
|
> > Hast du das gesucht? ;-) Ich glaube, er meint das, was in Python als List Comprehension bezeichnet wird. Die beiden folgenden Codeteile tun (im Prinzip) dasselbe:
1 | result = list() |
2 | for elem in liste: |
3 | result.append(machwas(elem)) |
und
1 | result = [machwas(elem) for elem in liste] |
Das ist hier nur ein bisschen syntaktisches Zückerchen, inspiriert von Haskell. Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp tuple), quasi einer unveränderlichen Liste, weil die keine append()-Methode haben (unveränderlich halt), so daß das erste Beispiel die Ergebnisse von machwas() dann nämlich erst in einer Liste sammeln und diese dann in ein Tupel umwandeln müßte.
Jack V. schrieb: > OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner > Klammerorgien gehasst, wenn ich damit mal zu tun hatte (und zwar noch, > bevor ich Python überhaupt kannte). Äh, Du meinst jetzt aber nicht Lisp, oder? ;-)
Sheeva P. schrieb: > Äh, Du meinst jetzt aber nicht Lisp, oder? Nein. Jede andere Sprache, die ich zu der Zeit kannte, kam mit erheblich weniger Klammern aus. Abgesehen davon: „God wrote in Lisp“ – ich selbst habe es nicht gelernt/genutzt, aber wenn Leute Lieder drüber schreiben, kann es ja auch nicht ganz verkehrt sein, oder?
:
Bearbeitet durch User
Nick M. schrieb: > Aber sublime macht aus einem "proc<tab> ein: > proc name {args} \ > { > > } Äh... ist der Backslash da wirklich notwendig? 8-O
"Die Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das jetzt seit 5 Jahren veröffentlicht ist." perl6 wird wohl viel eher als eigene, unabhängige Sprache gesehen. Und zum Teil auch als eine Totgeburt.
Egon D. schrieb: > Siehe mein Beispiel mit "switch": Tcl ahmt in vielen > Dingen C nach Das ist so wie mit Französisch, Italienisch und Spanisch. Gleicher Sprachstamm. Wer Französich kann, tut sich mit Italienisch leicht oder versteht es zumindest ansatzweise. Manche Französischen Wörter spricht man einfach italienisch aus und das passt dann. So wie Italiener sich leicht tun wenn die Spanier endlich mal langsam sprechen. Aber es gibt keinen Anspruch darauf, dass Fränzösich wie Italienisch und Tcl wie C verhalten muss. Und dass das alles von Latein abstammt, hab ich als Neusprachler unterschlagen. Alle Sprachen sind nur ein Ausdrucksmittel. Das gilt für C und für Python und für Russisch (Äquivalent zu APL). In der einen Sprache lässt sich etwas kompakter oder einfacher oder umständlicher oder klangvoller ausdrücken wie in der Anderen. Das Französisch die Sprache der Liebe ist ist genauso Quatsch wie dass Deutsche Spaß verstehen und Italiener bei Deutsch immer nur Karrrtoffel hören. Dafür kullern sich die Italiener warum die Bayern immer Grüß Gott sagen. Die verstehen nämlich cruscotto, was Armaturenbrett bedeutet. So wie halt die Zahlen in Französich ziemlicher Schwachsinn sind. Wer 92 wie "Vier (mal) zwanzig zwölf" ausspricht, kann nicht ganz dicht sein. Aber Käse können sie!
Das gilt aber nur so lange, wie man sich im gleichen Paradigma bewegt. https://de.wikipedia.org/wiki/Programmierparadigma Der Schritt von Perl zu Python ist kleiner als der zu Prolog.
:
Bearbeitet durch User
Sheeva P. schrieb: > Äh... ist der Backslash da wirklich notwendig? 8-O Ja. :-)) Ich schreib es aber anders, nämlich so wie eigentlich alle Anderen: { } { Dann braucht man den Backslash nicht. Und ja, auch das ist Unsinn. Aber ich kann es zugeben! Das macht mir mein Leben einfacher.
Nick M. schrieb: > Sheeva P. schrieb: >> Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die >> Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt. > > Nur nicht Tabs und LZ mischen, das hab ich schon verstanden. > Ist ja auch einleuchtend, denn so darf jeder das machen was einer > festlegt. > Wobei es jeder so machen kann, wie er mag, solang sich die Anderen daran > halten. > 8-/ Nein, sogar das ist dem Parser vollkommen wumpe -- jedenfalls, solange es nicht in derselben Datei passiert. Wenn Du Deinen Code also mit einer Indentierung von zwei Leerzeichen schreibst, kannst Du jederzeit Code laden, der sich an PEP8 hält, also vier Leerzeichen dafür benutzt. Da ist Python -- wie in vielen anderen Dingen -- ziemlich frei und setzt mehr auf Konventionen als auf Zwänge.
Irgendwann ist vielleicht mal der Punkt erreicht wo jemand sagt "He, die vorhandenen Sprachen sind jetzt langsam mal gut genug, jetzt können wir uns endlich aus Programmieren konzentrieren statt dauernd vermeintlich bahnbrechenden, inkompatiblen Neuerungen hinterherzuwarten" :) ... Wenn man auf konsequent andere Syntax steht: Forth bzw Postscript (letztere Sprache ist sogar tatsächlich verflixt elegant wenn man sich Beispiele ansieht die nicht von einem Druckertreiber zusammengestampft wurden :) )
Sheeva P. schrieb: > Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp > tuple), quasi einer unveränderlichen Liste, weil die keine > append()-Methode haben (unveränderlich halt), Konstante gibts nicht in Tcl. Man kann aber ein event (eine Funktion) drauf setzen wenn eine Variable, egal von wem, geändert wird. Eine n-Tupel im mathematischen Sinne wäre eine Liste. Daraus könnte man eine Liste von Listen machen oder flach in eine Liste schreiben. Das foreach kann dann bei letzteren wieder was schönes machen: foreach tuple1 tuple2 tuple2 in $listOfFlatTuples { ... Die andere Schreibweise wäre ein 'lmap' über eine Liste.
Sheeva P. schrieb: > Nein, sogar das ist dem Parser vollkommen wumpe -- jedenfalls, solange > es nicht in derselben Datei passiert. Also doch nicht wumpe. Ausser "wumpe" bedeutet für dich "zwingend erforderlich".
Andy D. schrieb: > "Die Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das > jetzt > seit 5 Jahren veröffentlicht ist." > > perl6 wird wohl viel eher als eigene, unabhängige Sprache gesehen. Und > zum Teil auch als eine Totgeburt. Ja, sie haben Perl6 jetzt in Rake umbenannt. Wobei eine der ultimativen Stärken von Perl das CPAN war, wo es -- ähnlich wie heute in Python -- Bibliotheken für nahezu alles gegeben hat. Keine Ahnung, wie das weitergehen soll... :-( Mir tut die heutige Situation von Perl in der Seele weh, schließlich hat es mich über zehn Jahre begleitet und war mir immer ein guter, treuer Freund. Heute benutze ich es nurmehr als Filter in der Shell:
1 | cat 507607.html | perl -pe 's/Andy D./andi d./g' |
an Stellen, wo andere zu sed(1) oder awk(1) greifen... wirklich schade. Aber gleichzeitig bin ich auch dankbar: Perl hat mich viel über Skriptsprachen und ihre Ausführungsmodelle, über Perl-Compatible Regular Expressions, und über krude Objektorientierung (bless...) gelehrt. Lustige Anekdote: vor vielen Jahren -- als Perl6 gerade im Gespräch und ich noch nicht zu Python gewechselt war, hat mir ein Lektor des Rheinwerk-Verlags angeboten, ein Buch über Perl6 zu schreiben... Heute sind wir vermutlich beide froh, daß ich damals abgelehnt habe. Und zu den besten Programmierbüchern, die ich je gelesen habe, gehört immer noch "Objektorientiert Programmieren mit Perl" von Damian Conway.
Nick M. schrieb: > Sheeva P. schrieb: >> Äh... ist der Backslash da wirklich notwendig? 8-O > > Ja. :-)) Oh, interessant. > Ich schreib es aber anders, nämlich so wie eigentlich alle Anderen: > { } { > Dann braucht man den Backslash nicht. Und ja, auch das ist Unsinn. > Aber ich kann es zugeben! Das macht mir mein Leben einfacher. Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine Rolle, oder verstehe ich da gerade etwas falsch? Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe. Auch in C, C++, JavaScript, Perl, PHP, Java, Scala, Kotlin -- und ein paar anderen Sprachen, die ich glücklich- und erfreulicherweise schon vergessen habe -- und sogar in LaTeX, CSS, HTML, XML, JSON, SVG, SQL, und wie das olle Gerümpel auch heißen mag, habe ich immer penibelst auf eine saubere Einrückung geachtet. Passiert mir ja ohne das schon oft genug, daß ich beim Lesen von Code in einer von zwei Situationen bin: entweder denke ich "Alter, was für ein Genie, so gut würde ich auch programmieren können" oder "Meine Güte, was für ein Scheiß, welcher Idiot hat das verbrochen". Am Ende stellt sich dann (für meinen Geschmack zu oft) heraus: ist beides von mir. Zum Glück ist die erste Situation noch häufiger -- und wenn sie das nicht mehr ist, dann suche ich mir was Neues. Blumenpflücken soll ja sehr entspannt sein.
Nick M. schrieb: > Egon D. schrieb: >> Siehe mein Beispiel mit "switch": Tcl ahmt in >> vielen Dingen C nach > > Das ist so wie mit Französisch, Italienisch und > Spanisch. Gleicher Sprachstamm. Fast -- aber nicht ganz dasselbe: Natürliche Sprachen werden letztlich beim Sprechen durch die Sprechenden geformt -- formale Sprachen haben einen Schöpfer, und der kann halt auch mal Fehlentscheidungen treffen :) > Aber es gibt keinen Anspruch darauf, dass Fränzösich > wie Italienisch und Tcl wie C verhalten muss. Wer redet von "Anspruch"? Du musst Tcl übrigens mir gegenüber nicht verteidigen :) Lange Zeit ist mir die Verwandtschaft zwischen Tcl und C gar nicht aufgefallen; ich kann (noch) kein C. Als ich mit Lernen anfing, stellte ich dann freudig erregt fest, dass ich einen Großteil der Steuerstruktur und einen Teil der Operatoren von C schon kenne. Nur die Ausnahme mit "switch" und "break" stach halt ins Auge; das hätte m.E. nicht sein müssen. > Alle Sprachen sind nur ein Ausdrucksmittel. Das gilt > für C und für Python und für Russisch (Äquivalent zu > APL). In der einen Sprache lässt sich etwas kompakter > oder einfacher oder umständlicher oder klangvoller > ausdrücken wie in der Anderen. Ja sicher -- aber (danke für die Vorlage) hier wurde ein "falscher Freund" geschaffen, der nicht hätte sein müssen. Mehr habe ich gar nicht gesagt.
Sheeva P. schrieb: > Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine > Rolle, oder verstehe ich da gerade etwas falsch? Ja, halbwegs schlecht geschauspielert. Es geht um das '\n' das durch das '\\' aufgehoben wird. Du kannst also beliebig viele LZ oder <tab> einfügen, was ja auch Whitespaces sind. Was aber nicht bedeutet, dass ich das sinnvoll finde. Sheeva P. schrieb: > Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht > für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung > dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe. Deine Hartnäckigkeit ist erschreckend! Wer hat hier jemals abgestritten, dass sauberes Formatieren einfach zum Handwerkzeug gehört? Oh, und das muss natürlich ein Monospaced Font sein, sonst klappt das nicht. Aber das ist ja loooogisch. **Pffff** Wie viele Compiler // Interpreter // Parser hast du schon geschrieben? Ich vermute das nähert sich extrem gegen Null. Sheeva P. schrieb: > und wie das olle Gerümpel auch heißen mag, habe ich immer penibelst auf > eine saubere Einrückung geachtet. Ah, wenn ich einen Dump einer XML-Nachricht mach, dann ist der eingerückt. Wenn ich die zum Server schick ist das ein schweinelanger Einzeiler. Weil sonst das Gejammer losgeht dass so viele unnötige Daten übertragen werden **heul**. Der Inhalt ist aber identisch. Genauso kann ich das auch empfangen, unnötige Whitespaces wirden als allererstes beim Parsen wegeworfen. OK, ist das jetzt sauber:
1 | void doit(int p1, int p2, // undsoweiterbiszumzeilenende |
2 | int p10, int p11) { |
Oder doch lieber so:
1 | void doit(int p1, int p2, // undsoweiterbiszumzeilenende |
2 | int p10, int p11) { |
Oder machen wir es lieber wie in Verlilog
1 | void doit(int p1, |
2 | int p2, |
3 | // undsoweiter
|
4 | int p10, |
5 | int p11) { |
oder so sieht man es auch:
1 | void doit(int p1, |
2 | int p2, |
3 | // undsoweiter
|
4 | int p10, |
5 | int p11) { |
Weißt du, wo ich <tab> und wo ich LZ getippt hab? Ist doch egal, sieht man ja nicht. Nur weil du es als sauber betrachtes, müssen das nicht Alle so sehen. Dem C-Compiler sind alle Varianten wurscht. Er überlässt meine persönlichen Vorstellungen weitestgehend mir. Versuch endlich mal Darstellung und Inhalt auseinander zu halten. Das sind zwei Dinger.
Egon D. schrieb: > Ja sicher -- aber (danke für die Vorlage) hier wurde ein > "falscher Freund" geschaffen, der nicht hätte sein müssen. Meinst du den Russen? Kennst du APL? https://de.wikipedia.org/wiki/APL_(Programmiersprache)
Andy D. schrieb: > Irgendwann ist vielleicht mal der Punkt erreicht wo jemand sagt "He, die > vorhandenen Sprachen sind jetzt langsam mal gut genug, jetzt können wir > uns endlich aus Programmieren konzentrieren statt dauernd vermeintlich > bahnbrechenden, inkompatiblen Neuerungen hinterherzuwarten" :) Naja, im Prinzip ist das ja zumindest bei den Skriptsprachen schon der Fall. Alle heute weit verbreiteten Sprachen stammen im Wesentlichen aus derselben Epoche, die allerdings damals noch geprägt war von Single-Core-CPUs. Heute ist die Situation allerdings anders, die meisten Prozessoren haben mehrere Rechenkerne und viele sogar mehrere Threads pro Rechenkern (Hyperthreading). Das verändert die Bedingungen, für die Skriptsprachen entwickelt werden. Python und Ruby zum Beispiel leiden an etwas, das sich "Global Interpreter Lock" nennt. Das ist wirklich nervig, weil es ein wirkliches Multithreading effektiv verhindert. CPython hat deswegen ein Modul namens multiprocessing mit im Prinzip derselben Syntax wie das multithreading-Modul, was die Sache wieder ein bisschen erträglicher macht. Lustigerweise kennen Jython und IronPython, die auf Java und C# basieren, sowas wie ein GIL nicht. Aber die haben ihre eigene Garbage Collection -- die zumindest unter Java mit dem ZeroGC etwas erträglicher geworden ist und vorher gerne unter Memory Leaks und anderen Nickeligkeiten gelitten hat. Insofern, kurz gesagt: die Hardware entwickelt sich weiter, und damit müßten das auch die Programmiersprachen tun. Aber die verbreitetsten Skriptsprachen sind noch aus einer Zeit der einzelnen Singlecore-CPUs. Mein damaliger Arbeitgeber Sun hat Java entwickelt, und da wir damals schon Maschinen mit mehreren Kernen hatten, ist das einer der wenigen Aspekte, in denen Java wirklich stark ist. Insofern, um Deine Frage zu beantworten: nein, die heutigen Sprachen sind noch lange nicht gut genug und werden es auch morgen nicht sein. Übermorgen vielleicht, ja. Es wird sich zeigen, welche überleben und welche nicht. Und dann lernen wir halt eine neue Sprache. Na und? Das tut nur den One-Trick-Ponies weh... und auch die werden dann entweder Blümchenpflücker oder Rentner. PS: Bevor ich hier wieder wegen der One-Trick-Ponies angekackt werde... Es gibt einige Softwareentwickler, die genau eine Sprache können und sich mit Händen und Füßen dagegen wehren, eine neue zu lernen. Aus meiner persönlichen Erfahrung liegt das oft daran, daß man mit der ersten Programmiersprache ja nicht nur die Sprache, sondern auch das Programmieren erlernen muß. Letzteres ist der wesentlich härtere Teil, und... für manche Menschen ist das so eine böse Erfahrung, daß sie sich die nicht noch einmal antun wollen. :-(
Nick M. schrieb: > Sheeva P. schrieb: >> Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp >> tuple), quasi einer unveränderlichen Liste, weil die keine >> append()-Methode haben (unveränderlich halt), > > Konstante gibts nicht in Tcl. Man kann aber ein event (eine Funktion) > drauf setzen wenn eine Variable, egal von wem, geändert wird. Ja, nein, vielleicht... Python hat zwei Datentypen für Listen, nämlich die Liste (list) und das Tupel (tuple). Ein Tupel als solches ist unveränderlich, aber ich kann einer Variablen, die ein Tupel hält, selbstverständlich immer ein anderes Tupel zuweisen. Denn Python ist dynamisch typisiert, bindet die Datentypen also an den Wert einer Variablen statt wie C, , C++ und Java, ans Symbol. > Eine n-Tupel im mathematischen Sinne wäre eine Liste. Daraus könnte man > eine Liste von Listen machen oder flach in eine Liste schreiben. Das > foreach kann dann bei letzteren wieder was schönes machen: > > foreach tuple1 tuple2 tuple2 in $listOfFlatTuples { Mehrfachzuweisung, nice. Python, anyone? Aber (unter anderem) deswegen gibt es in Python einen spezialisierten Iterable-Typ wie das Tupel. Damit Du sicher sein kannst, daß Dein Listelement nur genau drei Werte enthält... ;-)
Egon D. schrieb: > Habe ich das jetzt richtig verstanden: [...] > das in Python die Blockstruktur gar nicht AUSSCHLIESSLICH durch > Einrückungen definiert wird, sondern durch DOPPELPUNKTE > IN KOMBINATION MIT EINRÜCKUNG? > > Ist das korrekt bei mir angekommen? Und: Egon D. schrieb: > ich kann (noch) kein C Du sagst selbst, Du kennst weder Python noch C. Ich stelle es mir sehr schwierig vor, mit so wenig Wissen und ohne Erfahrung an dieser Diskussion hier aktiv teilzunehmen.
Nick M. schrieb: > Oh, und das muss natürlich ein Monospaced Font sein, sonst klappt das > nicht. Nein, das ist falsch, da auch in einer proportionalen Schrift das Leerzeichen eine fixe Breite besitzt.
Beitrag #6493125 wurde von einem Moderator gelöscht.
Irgendwer schrieb: > Egon D. schrieb: >> ich kann (noch) kein C > > Du sagst selbst, Du kennst weder Python noch C. > > Ich stelle es mir sehr schwierig vor, mit so wenig > Wissen und ohne Erfahrung an dieser Diskussion hier > aktiv teilzunehmen. Echt jetzt?! Falls mir mal SEHR langweilig sein sollte und ich Lust habe, mich provozieren zu lassen, sage ich bescheid. Im Moment ist das noch nicht der Fall.
Nick M. schrieb: > Egon D. schrieb: >> Ja sicher -- aber (danke für die Vorlage) hier wurde ein >> "falscher Freund" geschaffen, der nicht hätte sein müssen. > > Meinst du den Russen? Nein. Ich meine immer noch die switch-Anweisung in Tcl bzw. in C. Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend, dass Du nicht entweder zugeben kannst, dass ich Recht habe, oder mir nachweist, dass ich mit meinen Aussagen Unrecht habe. Das ist m.E. unter Deinem Niveau -- aber das ist letztlich Deine Sache. > Kennst du APL? Nein -- aber eins glaube ich ohne jeden Nachweis: Schlimmer geht es immer.
Nick M. schrieb: > Sheeva P. schrieb: >> Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine >> Rolle, oder verstehe ich da gerade etwas falsch? > > Ja, halbwegs schlecht geschauspielert. Es geht um das '\n' das durch das > '\\' aufgehoben wird. Du maskierst ein Newline. Wow. > Sheeva P. schrieb: >> Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht >> für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung >> dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe. > > Deine Hartnäckigkeit ist erschreckend! Wer hat hier jemals abgestritten, > dass sauberes Formatieren einfach zum Handwerkzeug gehört? Du bezeichnest eine von Pythons Eigenschaften als "Schwachsinn", weil es nunmal diese Eigenschaft hat. Ich hingegen habe praktische Erfahrung mit Python und weiß deswegen, daß das kein "Schwachsinn" ist. Wer von uns beiden kann jetzt wohl die qualifiziertere Aussage darüber treffen? > Wie viele Compiler // Interpreter // Parser hast du schon geschrieben? Keine Ahnung. Zehn, Zwanzig, Tausend? Wayne? > Ich vermute das nähert sich extrem gegen Null. Ach, vermute Du mal. ;-) > Weißt du, wo ich <tab> und wo ich LZ getippt hab? Ist doch egal, sieht > man ja nicht. Ja... und? Was ist Dein Punkt? > Nur weil du es als sauber betrachtes, müssen das nicht Alle so sehen. Schon wieder so eine Unterstellung. Kannst Du das wirklich nicht besser? Ja, ich halte das für eine gute Idee, weil es die Sicht des Übersetzers mit der des Entwicklers zusammenbringt. Das darfst Du aber gern anders sehen.
:
Bearbeitet durch User
Irgendwer schrieb: > Nein, das ist falsch, da auch in einer proportionalen Schrift das > Leerzeichen eine fixe Breite besitzt. Es würde mich nicht wundern, wenn hier jemand seinen Code im Blocksatz formatiert.
Jemand schrieb: > Irgendwer schrieb: >> Nein, das ist falsch, da auch in einer proportionalen >> Schrift das Leerzeichen eine fixe Breite besitzt. > > Es würde mich nicht wundern, wenn hier jemand seinen > Code im Blocksatz formatiert. Dann aber auch als Knittelvers.
Beitrag #6493258 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Nein. Ich meine immer noch die switch-Anweisung in Tcl bzw. > in C. Ah, OK. > Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend, > dass Du nicht entweder zugeben kannst, dass ich Recht habe, > oder mir nachweist, dass ich mit meinen Aussagen Unrecht > habe. Wegen dem switch / case? Ja, hab ich doch schon beantwortet. Nur weil deinem Empfinden nach Sprachen ähnlich sind, kannst du doch nicht fordern, dass die das switch und case gleich verwenden. Ist halt so. Soll ich mich darüber aufregen? Wenn ich mich über den Unterschied aufregen würde, werde die Konsequenz, dass es nur eine einzige Programmiersprache gäbe. Da wäre ich dagegen. Und zu deiner Beruhigung: Du hast weder Recht noch Unrecht. Dir gefällt es nicht. Und das ist absolut OK. Ich find auch nicht, dass C ähnlich zu Tkl ist. Da ist Python deutlich näher dran.
Jemand schrieb: >> Nein, das ist falsch, da auch in einer proportionalen Schrift das >> Leerzeichen eine fixe Breite besitzt. > > Es würde mich nicht wundern, wenn hier jemand seinen Code im Blocksatz > formatiert. D. Knuth, Literate Programming Muss man gelesen haben.
Sheeva P. schrieb: > also nur vier Tage beinhaltet und daher meckert, wenn ich ihm meinen > siebenstelligen Index mit allen Wochentagen zuweisen will. Jetzt sieht > mein Code so aus und funktioniert wieder perfekt: > plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() > DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', > 'Freitag', 'Samstag', 'Sonntag'] > days = list() > for i in plot_dayofweek.index: days.append(DAYS[i]) > plot_dayofweek.index = days > plot_dayofweek = plot_dayofweek.plot_bokeh( > kind='bar', show_figure=False, xlabel='Wochentag', > ylabel='Anzahl Beiträge', legend=None, colormap=['orange']) > > Da mein Code ansonsten keinerlei print()-Statements enthält, sondern Urgs, das wäre nicht mein Python Stil :-)
1 | ... |
2 | DAYS = 'Montag Dienstag Mittwoch Donnerstag Freitag Samstag Sonntag'.split() |
3 | plot_dayofweek.index = tuple( DAYS[i] for i in plot_dayofweek.index ) |
4 | ... |
Sheeva P. schrieb: > Wer diesen Thread > vorurteilsfrei und objektiv liest, erkennt schnell: von denen, die > Python tatsächlich benutzen, also: deren Urteil in ihrer eigenen > praktischen Erfahrung fundiert ist, hat kein einziger ein Problem mit > dieser Spracheigenschaft. Dann lies nochmal objektiv, denn diese Aussage ist definitiv falsch. Ich nutze Python weil es, nach Abwägen aller Vor- und Nachteile, für mich insgesamt das beste Gesamtpaket mitbringt. Das Whitespace-"Feature" zähle ich aber als großen Nachteil. Klar, ein Problem stellt es jetzt nicht dar. Es nervt einfach nur.
Angehängte Dateien:
-
pandas_demo.jpg
240 KB
@All from this thread, ich lass mal auch was vom Stapel ;-) Nachdem ich mit Python3 erst vor zwei Jahren angefangen habe, davor war Perl5 und bash mein Skripting Favorit bin ich nun aber von Python3 zumindest recht angetan. Die Problematik und die Diskussion über die Tab/Space Einrückungen sehe ich entspannt und lasse den Anderen den Diskussionsraum für Ihre Pros und Kontras. Was mich an Python begeistert ist die Möglichkeit Code erst einfach zu gestalten, damit es erst einfach läuft und dann in die Tiefe zu gehen um es falls nötig zu beschleunigen. Beispiel der Mittelwert-Bildung, siehe Anhang, und der daraus resultierenden Laufzeit-Optimierung mit den Möglichkeiten die Python so bietet. Und ich bin bei weitem kein Experte darin. Da geht sicherlich noch mehr. mw@linux-kwm1:~/Programming/Python/bsp >./random_average_python.py 17.96653366999999 mw@linux-kwm1:~/Programming/Python/bsp >./random_average_numba.py 2.573679684999661 mw@linux-kwm1:~/Programming/Python/bsp >./random_average_numba_parallel.py 0.793028295998738 Auch die Visualisierung mit matplotlib und pandas ist mir sehr ans Herz gewachsen und bestimmt auch vielen anderen. Deshalb habe ich meine Beispiele auch gleich angehängt, damit auch andere damit spielen können. Auf jeden Fall hilft mir Python im Arbeitsaltag sehr und hat in den vergangenen Monaten viel Mühe und Zeit bei Routine- Tätigkeiten eingespart. Jetzt beschäftige ich mich mit OpenCV und dann mit NN um in Richtung MI mein Wissen zu erweitern. Übrigens geb es gerade diese Woche im Handel vom Heise-Verlag das iX-Developer Magazin (Winter20/21) zum Thema MI und dreimal könnt Ihr raten in welcher Prog.-Sprache alle Beispiele verfasst sind. Markus
Le X. schrieb: > Ich nutze Python weil es, nach Abwägen aller Vor- und Nachteile, für > mich insgesamt das beste Gesamtpaket mitbringt. > Das Whitespace-"Feature" zähle ich aber als großen Nachteil. > Klar, ein Problem stellt es jetzt nicht dar. > Es nervt einfach nur. Oh, okay, Deine bisherigen Aussagen dazu hatte ich als weniger hart eingeschätzt.
Markus W. schrieb: > Nachdem ich mit Python3 erst vor zwei Jahren angefangen habe, > davor war Perl5 und bash mein Skripting Favorit bin ich nun > aber von Python3 zumindest recht angetan. > [...] > Da geht sicherlich noch mehr. Hast Du es mal mit Pypy ausprobiert? > Auch die Visualisierung mit matplotlib und pandas ist mir > sehr ans Herz gewachsen und bestimmt auch vielen anderen. +1 > Jetzt beschäftige ich mich mit OpenCV und dann mit NN um in > Richtung MI mein Wissen zu erweitern. Spannend... ich hacke gerade an einer Bewegungserkennung mit OpenCV auf einem RasPi4. Vor dem Hintergrund, daß ein Intel Nuc i3 mit Zoneminder und Motion dabei schon arg ins Schwitzen geraten ist, finde ich es sehr faszinierend, wie performant die ganze Geschichte mit OpenCV läuft. Dabei hat der kleine RasPi4 gerade einmal 125 BogoMIPS und der NUC immerhin 4190. Viel Spaß und Erfolg!
Sheeva P. schrieb: > Dabei hat der kleine RasPi4 gerade einmal 125 BogoMIPS und der NUC > immerhin 4190. Viel Spaß und Erfolg! Die BogoMIPS sind kein geeignetes Maß für die Verarbeitungsleistung eines Rechners, deswegen der Präfix Bogo (bogus = unecht, falsch). Der Wert dient lediglich der Kalibrierung von Busy-Loops für kurze Delays im Linux-Kernel. Speziell bei ARMs hat der Wert praktisch überhaupt nichts mehr mit der Rechenleistung zu tun: https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays Dein Raspi hat jedenfalls deutlich mehr als 125/4190 der Rechenleistung deines NUC.
Yalu X. schrieb: > Dein Raspi hat jedenfalls deutlich mehr als 125/4190 der Rechenleistung > deines NUC. Klar, aber daß so ein winziger RasPi4 mit OpenCV schneller ist als ein i3-5010U mit Zoneminder (oder noch schlimmer: Motion), finde ich trotzdem enorm beeindruckend. Übrigens habe ich mich vertan: der RasPi 3 B+ war der mit den 125 BogoMIPS, mein RasPi4 kommt auf 270. ;-)
Nick M. schrieb: >> Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend, >> dass Du nicht entweder zugeben kannst, dass ich Recht habe, >> oder mir nachweist, dass ich mit meinen Aussagen Unrecht >> habe. > > Wegen dem switch / case? > Ja, hab ich doch schon beantwortet. Nur weil deinem > Empfinden nach Sprachen ähnlich sind, kannst du doch > nicht fordern, dass die das switch und case gleich > verwenden. > > [...] > > Ich find auch nicht, dass C ähnlich zu Tkl ist. [...] Nun, ich gestehe, dass ich die Differenz zwischen uns nicht ausgerechnet in DIESEM Punkt vermutet hätte. Aber gut; ich nehme es zur Kenntnis.
Beitrag #6497513 wurde von einem Moderator gelöscht.
Beitrag #6497521 wurde von einem Moderator gelöscht.
Beitrag #6497544 wurde von einem Moderator gelöscht.
Beitrag #6497547 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Das ist jetzt kein besonders gutes Beispiel, fürchte ich. Die > Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das jetzt > seit 5 Jahren veröffentlicht ist. Da Perl6 allerdings nicht > abwärtskompatibel ist, ist der allergrößte Teil der Welt noch mit Perl5 > unterwegs, was die Perl-Entwickler vor die dumme Situation stellt, > anstatt einer Perl-Version jetzt zwei pflegen zu müssen. Irgendwann > werden sie in den sauren Apfel beißen müssen und Perl5 erst als > deprecated und dann als EOL deklarieren, oder die Entwicklung von Perl6 > einstellen müssen, um ihre Ressourcen zu konsolidieren. Ich bin gerade beim "Python-Stöbern" über diesen Thread gestolpert und wollte nur am Rande etwas korrigieren: Also Perl5 und Perl6 haben sich getrennt. Perl6 heißt jetzt Raku und ist eine eigenständige Sprache. Perl7 (Die 6 hat man jetzt aus gutem Grund übersprungen.) wurde als Nachfolger von Perl5 angekündigt und wird abwärtskompatibel sein. https://de.wikipedia.org/wiki/Raku_(Programmiersprache) https://www.perl.com/article/announcing-perl-7/?ref=alian.info Gruß Jay
Beitrag #6630771 wurde von einem Moderator gelöscht.
Danke für diesen extrem nützlichen Kommentar. Das hat sich richtig gelohnt, diesen alten Thread wieder aufzuwärmen.
Danke für diesen extrem nützlichen Kommentar. Das hat sich richtig gelohnt, diesen alten Thread wieder aufzuwärmen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.