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.
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.
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
procProc1{num}{
2
puts"Proc $num"
3
}
4
5
procProc2{num}{
6
puts"Proc $num"
7
}
8
9
for{seti1}{$i<3}{incri}{
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.
[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]
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 ;-)
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
[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 ?"
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 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?
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 …
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:
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:
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:
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:
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.
>> 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.
>> 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?
"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!
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:
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.
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.
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.
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.
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 )
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.
@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.
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
Thread beobachten
Seitenaufteilung abschalten