was ist das besondere an der programmiersprache Python?

Das ist meine meine Erfahrung mit Python. Ob man es verwenden möchte 
kann ja jeder selbst entscheiden.

Für schnelle Experimente finde ich die Sprache sehr schön.
- Als Scriptsprache muss kein Compiler aufgesetzt werden.
- Die Bibliothek bringt viele Funktionen, wie z.B. Codierungen, Parser 
und Webanfragen mit.
- Fehler werden mit Exception und Begründung geworfen und führen nicht 
einfach zu einer Accessviolation.
- Die Syntax ist übersichtlicher als bei anderen Scriptsprachen.

Als Nachteil für größere Projekte empfinde ich die fehlende Typisierung. 
Viele Fehler in Python würde in C/C++ der Compiler als Typfehler melden 
und es nicht beim Aufruf eine Fehlermeldung geben.

Python bringt aber nur eine Vorteil, wenn man nicht in Pointern, sondern 
abstrakten Objekten denkt. z.B. wenn ich prüfen möchte, ob ein Objekt in 
einer Liste ist schreibe ich in Python einfach

1

if "myText" in Liste:

Wenn man das stattdessen mit Iteratoren macht dann bringt Python 
natürlich keine Vorteil. Das erfordert aber ein Umdenken, wenn man aus 
der C Welt kommt.

Heiner schrieb:
> Das ist Teil eines größeren Plans, Konstrukte möglichst nahe an der
> natürlichen Sprache zu halten.

Was direkt zu COBOL führt: ;-)
SUBTRACT Fed-Tax From Total-Tax Giving Soc-Sec-Tax.

nichts schrieb:
> Eine "Programmiersprache", die per
> wrapper-Funktionen mit richtigen Programmiersprachen kommuniziert und
> ihre Libs nutzt. Pfui Deibel.

M.a.W: Alle Programmiersprachen, deren Datentypen und Aufrufverfahren 
nicht mit den C Konventionen konform gehen, sind von Übel?

osman schrieb:
> Kann jemand erklären, was ist das besondere an der programmiersprache
> Python?

[x] es ist nicht Perl
[x] es ist nicht PHP
[x] es ist nicht C
[x] es ist nicht Java

> Ich habe bisher keine Kenntnisse über Python. Vor ein paar Jahren hörte
> man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur
> noch Python. Warum?

Weil "man" (?) an komischen Stellen "hört"? Warum ist das wichtig, was 
man irgendwo hört? Programmiersprachen sind wie das Wetter. Oder 
(Damen-)Mode. Heute so, morgen so.

Ich glaube ja, es liegt daran, das die RaspBerry Pi Erfinder Python toll 
fanden und es gepushed haben. Ansonsten ist das eine ganz normale 
Skriptsprache. Kennst du eine, kennst du alle.

Es gäbe da auch noch Javascript. Oder Lua. Ruby. Such dir was aus. 
Manchmal hast du auch gar nicht besonders viel Auswahl.

PS: da denkt man nichts Böses. Man denkt einfach nur "YASL!". Und dann 
ist da https://github.com/yasl-lang/yasl
Das ist doch ein Witz! Bitte, das muß doch ein Witz sein!!1elf!

osman schrieb:
> Kann jemand erklären, was ist das besondere an der programmiersprache
> Python?
> Ich habe bisher keine Kenntnisse über Python. Vor ein paar Jahren hörte
> man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur
> noch Python. Warum? Was ist an Python so gut?

Python legt einen besonderen Fokus aus Lesbarkeit und kompakten Code, 
ist besonders einfach zu erlernen (in Großbritannien wird es sogar schon 
an einigen Grundschulen gelehrt) und gleichzeitig durch seine 
umfangreiche interne und externe Infrastruktur an Paketen und Modulen 
ausgesprochen mächtig. Wo man sich bei anderen Sprachen seine Module 
zusammensuchen muß, um -- zum Beispiel -- CSV- oder JSON-Dateien lesen 
und parsen zu können, bringt Python bereits fertige Module mit.

Obendrein ist Python sehr flexibel; die Sprache bietet eine 
hervorragende Anbindung an C und mit boost::python auch an C++ und kann 
in beiden Fällen sowohl als Gluesprache, als auch als interne 
Skriptsprache genutzt werden. Die Python-Interpreter in Java und .NET 
integrieren sich wunderbar in die jeweiligen Ökosysteme, und wer es 
besonders performant haben will, nimmt anstelle des 
Standard-Interpreters CPython einfach Pypy mit seinem JIT-Compiler.

Und dann, wie gesagt, die Infrastruktur. Es gibt so ziemlich nichts, das 
sich nicht mit Python machen oder ansprechen läßt. Obendrein bringt 
Python sehr mächtige Pakete für Aufgaben der Datenverarbeitung, -analyse 
und -visualisierung, was dazu führt, daß es sowohl in der 
wissenschaftlichen Community, als auch bei den Data Scientists besonders 
beliebt ist. Wohl auch deswegen gibt es so ziemlich kein Framework in 
den Bereichen Distributed Computing, Machine Learning und Natural 
Language Processing, das nicht mit einer leistungsfähigen 
Python-Schnittstelle ausgestattet ist.

Ich selbst hatte auch zuerst Vorbehalte gegenüber Python, gerade wegen 
der Sache mit dem Whitespace. Trotzdem habe ich festgestellt, daß eine 
Menge Projekte auf Python als Skriptsprache setzten, zum Beispiel 
OpenOffice.org, das K Desktop Environment, sowie PostgreSQL. Warum, habe 
ich mich gefragt, nutzen die ausgerechnet Python? Nun, ich habe mir dann 
irgendwann an einem lauschigen Winterabend mal einige kleinere Tutorials 
angeschaut und ein paar kleine Programme gebastelt, und... auf einmal 
war das mit dem Whitespace gar nicht schlimm, die Programme waren -- im 
Vergleich zu meiner damaligen Standard-Skriptsprache Perl -- viel 
schneller und stabiler, und die Fehlermeldungen wesentlich 
aussagekräftiger. Und, meine Güte, endlich mal eine gute Implementierung 
von Objektorientierung statt dem fiesen Gehassel in Perl5!

Und heute? Nach deutlich über zehn Jahren mit Python bin ich immer noch 
verliebt. In all dieser Zeit habe ich es nicht ein einziges Mal 
geschafft, den Interpreter zum Absturz zu bringen. Sogar der 
Standard-Interpreter ist etwa doppelt so schnell wie Ruby, Pypy dagegen 
-- je nach Anwendungsfall -- nochmals deutlich schneller, über die 
Projekte und Jahre würde ich etwa Faktor sechs bis acht schätzen. Ich 
mache so ziemlich alles in Python: Numbercrunching, Datenanalyse und 
-visualisierung sowohl auf FatClients als auch im Web, Websoftware mit 
Flask, GUI-Software mit Tkinter/Tix und Qt, ... oft ist es sogar so, daß 
ich mir die Python-API einer Software ansehe, wenn sich deren eigene 
Dokumentation mir nicht erschließen will.

Für mich ist der wesentliche Unterschied zwischen meiner alten 
Standardskriptsprache Perl und meiner neuen, Python: in Perl muß ich mir 
Mühe geben und sehr diszipliniert arbeiten, um saubere, les- und 
wartbare Programme zu schreiben. In Python muß ich mir Mühe geben und 
diszipliniert sein, um unlesbare Programme zu schreiben.

Eine Geschichte, die der meinen ganz ähnlich zu sein scheint, ist 
übrigens die von Eric S. Raymond, besser bekannt als Autor von "The 
cathedral and the bazaar" und der Fetchmail-Software. Wie er sich in 
Python verliebt hat, beschreibt er hier: [1].

[1] https://www.linuxjournal.com/article/3882

PS: Es hat hier einige negative Äußerungen gegeben, die allerdings 
überwiegend zwei Eigenschaften haben: die Autoren haben offensichtlich 
nicht die geringste Erfahrung mit der Sprache, und ihre Ausführungen 
beschäftigen sich im Wesentlichen mit ihren engstirnigen Vorurteilen 
anstatt mit valider Kritik. Die einzige valide Kritik, die ich hier 
gelesen habe, ist die Sache mit dem Whitespace. Und ja, das kann hin und 
wieder genauso nerven wie die Klammerorgien anderer Sprachen, aber mit 
einem guten Editor (in meinem Falle dem GNU Emacs) ist das sehr gut 
beherrschbar. Andererseits ist gerade diese Eigenart einer der 
wichtigsten Gründe dafür, warum Python-Code so besonders gut les- und 
wartbar ist -- zusammen mit der Designentscheidung, auf krude 
syntaktische Konstrukte ("syntaktischen Zucker") weitestgehend zu 
verzichten. Hör' nicht auf die Meckerzicken und Miesmacher, sondern 
probier' Python einfach aus und mach Dir ein eigenes Bild davon. Aber 
bitte, benutz unbedingt einen guten Editor, der zumindest 
Syntax-Highlighting und automatische Einrückung unterstützt, richtig 
gute wie der Emacs können allerdings auch Autocompletion und mehr. Viel 
Spaß! ;-)

just everything schrieb:
> Nick M. schrieb:
>
>> Ruby: Mitte 1990
>> Perl: 1987
>> Tcl: 1988
>> PHP: 1995
>> Python: Anfang 1990
>>
>> Die liegen innerhalb eines Jahrzehnts und haben sich bis jetzt gehalten.
>
> Ja, aber auf sehr unterschiedlichen Rankings:
> 
https://www.informatik-aktuell.de/aktuelle-meldungen/2019/januar/tiobe-index-die-aktuellen-top-programmiersprachen-im-ranking.html
> Ich glaube nicht, das die genannten Python den dritten Platz streitig
> machen werden.

Naja, je nachdem, welchen Programmiersprachenindex man bemüht und wie 
diese ihre Daten und Rankings erheben, ist Python immer auf einem der 
Plätze 1 bis 3. Wobei man sagen muß, daß Python keine Konkurrenz zu 
kompilierten Sprachen wie C, C++ oder Java ist, sondern vielmehr eine 
Ergänzung -- oder umgekehrt, die kompilierten eine Ergänzung für eine 
leistungsfähige und moderne Skriptsprache ist, je nachdem aus welcher 
Perspektive man das konkret betrachten will. Aber bei den Skriptsprachen 
hat Python bereits seit geraumer Zeit in allen mir bekannten Indizes 
gewonnen.

Hier im Thread hat jemand geschrieben, daß man nicht wissen könne, wie 
es in zehn oder zwanzig Jahren aussieht. Das ist natürlich einerseits 
richtig, vielleicht gibt es morgen eine enorme technische (R)Evolution, 
vielleicht verbocken die Entwickler von Python die nächste Version, oder 
womöglich entwickelt sich PHP sogar doch noch vom One-Trick-Web-Pony zu 
einer echten General-Purpose-Sprache. Aber wenn man sich die Entwicklung 
der beliebtesten Sprachen über die letzten Jahre ansieht, stellt man 
recht schnell fest, daß die Entwicklungen, Trends und Veränderungen hier 
ziemlich langsam vonstatten gehen. Und wenn man auf die Umfragen von 
Stackoverflow schaut, wo Python seit Jahren und immer noch am Häufigsten 
als "Most Wanted" genannt wird, wird schnell klar, daß der Siegeszug von 
Python wohl noch lange nicht gestoppt ist. Und das ist auch kein Hype, 
sondern eine Entwicklung, die sich seit sehr, sehr vielen Jahren und 
ausgesprochen stetig und stabil abzeichnet.

AtariST schrieb:
> Allerdings wird Python weniger für GUI Anwendungen benutzt,
> sondern für Programme auf der Konsole oder beispielsweise für die
> Programmierung von Plugins.

Wenn man sich die (sehr unvollständige) Liste von Python-Software bei 
Wikipedia [1] anschaut, stellt schnell fest, daß das nicht stimmt. 
Python wird sehr häufig auch für GUI-Software benutzt oder in 
GUI-Programme eingebettet, nur: der Anwender merkt davon meistens 
nichts, es werden dieselben Toolkits benutzt wie bei anderen GUIs.

[1] https://en.wikipedia.org/wiki/List_of_Python_software

Bastelmumie schrieb:
>> Was ist an Python so gut?
> Python ist ungiftig.

Beißt sich aber mit Squirrel-Mail. :)

W.S. schrieb:
> Ich halte das für gequirlten Irrsinn. Programmiersprachen sollen
> gefälligst klar lesbare Zeichen/Worte haben, um damit Blöcke zu
> kennzeichnen! Aber hier bei Python haben wir stattdessen
> unterschiedliche Anzahl von 'white space' Zeichen!
>
> Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt?
> Nein, nicht mit mir.

Das wird immer wieder als das große "Problem" aufgetan. Irgendwie 
verstehe ich das nicht. Es erzwingt halt vernünftige Einrückung. Die 
mache ich sowieso, deshalb stört mich das auch nicht. Wenn du immer wie 
Kraut und Rüben einrückst (und auch noch munter Tabs und Spaces 
mischst), dann ist das natürlich was anderes. Das liegt dann aber an dir 
und nicht an der Sprache.

Nick M. schrieb:
> Also geht es um Interpretierte/Scriptsprachen. Jeder Softwareentwickler
> muss eine Scriptsprache können.

Das sehe ich auch so. Welche das ist, spielt eigentlich keine so große 
Rolle. Eine Sprache mit großer Verbreitung hat allerdings noch den 
Vorteil, dass man besonders viel darüber im Internet findet.

> Python hab ich schon mal gehört. -) Brauch ich nicht, erscheint mir als

Hmm, wenn man sich das anschaut:

> Witzig ist, wann die Sprachen entwickelt wurden:
> Ruby: Mitte 1990
> Perl: 1987
> Tcl: 1988
> PHP: 1995
> Python: Anfang 1990

Warum siehst du dann ausgerechnet Python als Hype an?

Heiner schrieb:
> In C und ähnlichen Sprachen würde es ungefähr heißen:
> for (int i = 0; i < max; i++) { ...
> ... und dann benutzt man i z.B. für den Zugriff auf ein Array. Was die
> drei Blöcke in der Klammer bedeuten, muss man selbst wissen. Die Syntax
> gibt darauf keinerlei Hinweise. Python macht daraus ein einfaches:
> for abc in xyz:
> ... wobei in den meisten Fällen die Iterationsvariable ganz wegfällt,
> weil xyz selbst eine iterierbare Klasse ist und "selbst weiß, wie man
> sich aufzählt", also nicht darauf angewiesen ist, dass du
> Abbruchbedingung oder ähnliches angibst. Ob das zu dem beabsichtigen
> hübschen Code führt, hängt ganz wesentlich vom Programmierer ab.

Wobei C++ das ja in ähnlicher Form mit range-based for übernommen hat. 
Da kann man schreiben:
for (auto abc: xyz)

Axel S. schrieb:
> Weil "man" (?) an komischen Stellen "hört"? Warum ist das wichtig, was
> man irgendwo hört? Programmiersprachen sind wie das Wetter. Oder
> (Damen-)Mode. Heute so, morgen so.

Naja, zu einer fast 30 Jahre alten Sprache, deren Beliebtheit 
kontinuierlich steigt, passt diese Aussage nicht so ganz.

> Ich glaube ja, es liegt daran, das die RaspBerry Pi Erfinder Python toll
> fanden und es gepushed haben.

Auch im KI-Bereich ist Python weit verbreitet.

Sheeva P. schrieb:
> Für mich ist der wesentliche Unterschied zwischen meiner alten
> Standardskriptsprache Perl und meiner neuen, Python: in Perl muß ich mir
> Mühe geben und sehr diszipliniert arbeiten, um saubere, les- und
> wartbare Programme zu schreiben. In Python muß ich mir Mühe geben und
> diszipliniert sein, um unlesbare Programme zu schreiben.

Gut, Perl ist ja dafür verschrien, dass damit meist "write-only"-Code 
geschrieben wird. Allerdings tue ich mich in Python auch recht schwer 
damit, Code zu schreiben, den ich ein Jahr später wieder leicht 
verstehen kann und finde, dass man gerade dort besonders diszipliniert 
arbeiten muss, um lesbaren Code zu erhalten. Bei C++ gelingt es mir 
jedenfalls deutlich besser. Ich weiß aber nicht so genau, woran das 
liegt. Vielleicht daran, dass Python  einfach zu viele Schweinereien 
erlaubt oder dass es nicht so streng typisiert ist.

Nano schrieb:
> Sheeva P. schrieb:
>> Das ist natürlich einerseits
>> richtig, vielleicht gibt es morgen eine enorme technische (R)Evolution,
>
> Rust im Bereich der compilierten Sprachen und der Systemprogrammierung.
>
> C und C++ wird es allerdings dennoch nicht eretzen, aber zumindest
> ergänzen und bei Neuentwicklungen dürfte es zunehmend öfters eingesetzt
> werden.

Einerseits sehe ich das (noch?) lange nicht, daß Rust eine größere Rolle 
spielt, im Moment scheint das Momentum eher bei Go zu liegen. 
Andererseits spielt Rust in einer Diskussion, in der es um die 
(meistens) interpretierte General-Purpose-Skriptsprache Python geht, 
wohl auch keine Rolle.

Warum das "meistens"? Weil Python natürlich kompiliert werden kann, 
entweder in (interpretierten) Bytecode -- oder auch in nativen 
Maschinencode.

Rolf M. schrieb:
> Sheeva P. schrieb:
>> Für mich ist der wesentliche Unterschied zwischen meiner alten
>> Standardskriptsprache Perl und meiner neuen, Python: in Perl muß ich mir
>> Mühe geben und sehr diszipliniert arbeiten, um saubere, les- und
>> wartbare Programme zu schreiben. In Python muß ich mir Mühe geben und
>> diszipliniert sein, um unlesbare Programme zu schreiben.
>
> Gut, Perl ist ja dafür verschrien, dass damit meist "write-only"-Code
> geschrieben wird. Allerdings tue ich mich in Python auch recht schwer
> damit, Code zu schreiben, den ich ein Jahr später wieder leicht
> verstehen kann und finde, dass man gerade dort besonders diszipliniert
> arbeiten muss, um lesbaren Code zu erhalten. Bei C++ gelingt es mir
> jedenfalls deutlich besser. Ich weiß aber nicht so genau, woran das
> liegt. Vielleicht daran, dass Python  einfach zu viele Schweinereien
> erlaubt oder dass es nicht so streng typisiert ist.

Vermutlich Übungssache, bei mir ist es nämlich genau andersherum. Aber 
ich schreibe jeden Tag etwas in Python und alle paar Wochen und manchmal 
auch Monate etwas in C++ -- wenn das bei Dir andersherum ist, könnte das 
die Ursache sein.

FFFFFFFF schrieb:
> Sheeva P. schrieb:
>> Python legt einen besonderen Fokus aus Lesbarkeit und kompakten Code
>
> Wie gut eine Sprache lesbar ist liegt (fast) immer im Schreibstil des
> Authors. Ich kann auch in C/C++ wunderbar formatierten Code schreiben.

Die Lesbarkeit von Code hängt allerdings nicht nur von der Formatierung 
ab.

> Diese Tabs/Leerzeichen von Python finde ich z.B. grausam lesbar und irre
> schlecht wartbar.

Das ist, wie so vieles, reine Übungssache. Jedenfalls erzwingt diese 
Eigenschaft eine saubere Blockeinrückung, und mir ist unverständlich, 
wie das die Lesbarkeit verschlechtern sollte, das ist ja völlig abstrus.

> Jeder Profi den ich kenne lehnt Python als vollwertige Sprache ab,
> alleine aufgrund der Einrückungen.

Dann kennst Du vielleicht die falschen "Profis". Ich selbst jedenfalls 
bin Profi und arbeite mit vielen Profis zusammen, und sogar die, die 
anfangs noch viel lieber Ruby haben wollten, finden Python mittlerweile 
toll.

Es ist auch schon sehr merkwürdig, daß  Python in der 
StackOverflow-Survey von 2020 bei den "Most Wanted" auf Platz 1 ist -- 
wie auch schon seit 2017 und mit weiterhin steigender Tendenz. Ähnliches 
gilt für die bekannten Programmiersprachenindices, Red Monk, PYPI und 
TIOBE: überall liegt Python ganz weit vorne. Ich weiß ja nicht, aber 
wenn die von mir befragten Profis alle so weit daneben liegen... also 
ich würde mir dann neue Profis zum Befragen suchen.

> Natürlich kann man damit kurze Scripte schreiben, dafür reicht es.

Wobei man natürlich dazu sagen muß, daß schon ein kurzes Python-Skript 
mindestens genau so viel Funktionalität hat, wie ein viele, viele Seiten 
langes Programm in C++, Java oder gar C. Aber man kann auch sehr gut 
längere Programme mit Python schreiben, das funktioniert ganz wunderbar 
-- zum Beispiel die Kollaborations- und Workflowmanagementsoftware 
TACTIC [1] mit knapp 200.000 LOC, die eventbasierte Netzwerkengine 
Twistet mit knapp 150.000 LOC, oder das Webframework Django und den 
OR-Mapper SqlAlchemy mit jeweils über 110.000 LOC.

> Aber ich würde niemals damit einen µC oder ein größeres Projekt umsetzen.

Wenn Du das wählen und entscheiden kannst, ist das ja Deine Sache und 
schön für Dich. Andere können und machen das -- und die meisten 
vollkommen freiwillig.

Aber, ja, Pythons Natur als Skriptsprache, seine dynamische Typisierung 
und die Sache mit dem Whitespace polarisieren. Die ersten beiden 
Eigenschaften werden von den Verfechtern der Einzig Wahren Lehre (tm) 
der kompilierten, streng typisierten Sprachen abgelehnt, und die Sache 
mit dem Whitespace hat ja auch bei mir anfangs große Skepsis ausgelöst. 
Aber nachdem ich die Erfahrung gemacht habe, kann ich mit voller 
Überzeugung sagen: das ist nur eine Sache der Gewohnheit, mehr nicht. In 
der praktischen Nutzung ist das vollkommen irrelevant.

[1] https://southpawtech.com/tactic-open-source/

Sheeva P. schrieb:
> Es ist auch schon sehr merkwürdig, daß  Python in der
> StackOverflow-Survey von 2020 bei den "Most Wanted" auf Platz 1 ist --
> wie auch schon seit 2017 und mit weiterhin steigender Tendenz.

Das ist mir auch ein Rätsel. WIrd halt von den ganzen Noobs gepusht und 
dass das im Zusammenhang mit Raspberry Pi so gehypt wurde.

Mikrocontroller -> C/C++/demnächst R... mir ist der Name entfallen
Desktop -> Java/C#/C++
Server -> Java/C/C++
Scripte -> Python

Sheeva P. schrieb:
> Die Lesbarkeit von Code hängt allerdings nicht nur von der Formatierung
> ab.

Doch, fast immer.

Sheeva P. schrieb:
> Das ist, wie so vieles, reine Übungssache. Jedenfalls erzwingt diese
> Eigenschaft eine saubere Blockeinrückung, und mir ist unverständlich,
> wie das die Lesbarkeit verschlechtern sollte, das ist ja völlig abstrus.

Ach, jetzt soll ich eine furchtbare Formatierungseigenschaft üben, bis 
ich diese kann? Nein danke, haben doch fast alle anderen 
Programmiersprachen etwas Klammern artiges - und das ist auch gut so 
liebe Genossinnen und Genossen.

Auch ich habe schon Python verwenden müssen. Eine Katastrophe. In C/C++ 
kann ich praktisch wie wild drauf los schreiben. Natürlich gebe ich mir 
da schon etwas Mühe - am Ende jage ich einen Formatter drüber und gut 
ist.

Bei Python eine Einrückung vergessen? Pech gehabt, stundenlange 
Fehlersuche.

Ganz abgesehen davon muss nicht jeder Hinz und Kunz in meinem 
Programmcode rumfuhrwerken (es sei denn es ist openSOurce). Und die 
Ausführgeschwindigkeit kommt noch oben drauf.

Ich sehe keinen praktischen Grund auf einem mikrocontroller python 
einzusetzen., bitte nenne mir einen. Hardwareabstraktion? Man sollte 
seinen µC kennen und das Manual + Registerebene verstanden haben - dann 
braucht man keine Hardwareabstraktion mehr. lwip, freeRTOS - gibts das 
in python? Weiß ich nicht, das aber dann C mit Python auf einem µC 
koppeln ist wie mit Atomwaffen auf Spatzen zu schießen.

Sheeva P. schrieb:
> Andere können und machen das -- und die meisten
> vollkommen freiwillig.

Die tun mir auch wirklich leid. Wenn ich im professionellen Umfeld mit 
micropython kommen würde, wäre ich bald arbeitslos - so finde ich auf 
gängigen Jobportalen kein einziges Stellenangebot wenn ich danach suche. 
Ganz abgesehen davon, dass ich in C automatisch hardware nah denke - das 
hat schon Linus gesagt und recht hat er.

Wenn µC irgendwann mal per standard im GHz Bereich sind können wir 
nochmal über µPython reden.

Für die openSOurce Community ganz nett, für ernsthafte Entwicklung eher 
drittrangig.

Ben S. schrieb:
> Bei Python eine Einrückung vergessen? Pech gehabt, stundenlange
> Fehlersuche.

Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange 
Fehlersuche.


>Für die openSOurce Community ganz nett, für ernsthafte Entwicklung eher
drittrangig.
Irgendwie hört sich das an, als ob aus openSOurce keine ernsthaften 
Entwicklungen entstehen.....

In diesem Forum ist man wahnsinnig schnell polemisch.
Keiner zwingt einen zu einer Programmiersprache.

Ich nutze verschiedene. Hab jahrzentelang Klammern gesetzt.
Das Einrücken in Python war am Anfang ungewohnt aber nach wenigen
Übungen in Fleisch und Blut übergegangen.
Meine bisherigen Python Softwarefehler hatte nie damit zu tun,
dass ich falsch eingerückt hatte.

Ein Aspekt der bisher nicht genannt wurde:
Ich nutze statt Matlab nur noch Python (meist über Jupyter Notebooks).
Gerade für wissenschaftliche Berechnungen bietet die Sprache viel.

Klaus H. schrieb:
> Ben S. schrieb:
>> Bei Python eine Einrückung vergessen? Pech gehabt, stundenlange
>> Fehlersuche.
>
> Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange
> Fehlersuche.

Dann formatierst du deinen Code nicht ordentlich...

Klaus H. schrieb:
> Keiner zwingt einen zu einer Programmiersprache.

Das soll bei professioneller Entwicklung in Unternehmen schon mal als 
Nebeneffekt der Berufs- und Arbeitsplatzwahl vorkommen.

Klaus H. schrieb:
> Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange
> Fehlersuche.

Eine Klammer kann ich hingegen nicht vergessen. Ne' Einrückung schon.

//.|.\\ schrieb:
> Eine Klammer kann ich vergessen und dann fängt
> die Suche an, wo die vergessen wurde.

gequirlte scheisse. Die fehlende Klammer erzeugt eine Fehlermeldung. Die 
letzte Zeile eines Ifs in python nicht eingerückt ergibt keine 
Fehlermeldung 🙄.

Aktiv Unsinn machen ist eigentlich in keiner Programmiersprache 
besonders schwer.

Typ schrieb:
> Messdaten können mit Python super einfach aufbearbeitet werden, zusammen
> mit Jupyter kann man direkt eine präsentable Seite vorweisen.

Das ist auch ein guter Anwendungszweck von Python: Verarbeitung von 
wissenschaftlichen Daten. Aber in der Desktop/Server/µC-Programmierung 
für mich ein nogo - höchstens für kleine Testtools oder so. Aufm 
raspberry für die, die kein C/C++ können.

Walter T. schrieb:
> Aktiv Unsinn machen ist eigentlich in keiner Programmiersprache
> besonders schwer.

Ein tab/Klammer kann auch mal durch Unachtsamkeit verloren gehen.

Walter T. schrieb:
> Aktiv Unsinn machen ist eigentlich in keiner Programmiersprache
> besonders schwer.

Passiv auch. Der subtile Unterschied zwischen { und ( erschliesst sich 
bei ungeeigneten Fonts und hochauflösenden Bildschirmen optisch nicht 
immer sofort. Einrückung ist schwerer zu übersehen.

Typ schrieb:
> Messdaten können mit Python super einfach aufbearbeitet werden, zusammen
> mit Jupyter kann man direkt eine präsentable Seite vorweisen.

Reportgenerierung ist der Ursprung von Perl. Sowas kann mit 
Schriptsprachen viel einfacher sein als mit C/C++.

Ich werde auch immer mehr zum Python-Benutzer im Scriptingbereich.

Die Vorteile wurden ja schon alle genannt. Die schnellste 
Interpreter-Sprache ist es sicher nicht, aber dank der vielfältigen 
Module sehr mächtig und imallgemeinen gut zu lesen, natürlich kann man 
auch in Python Konstrukte bauen die schwer zu verstehen sind.

Einschränkungen gibt es leider für "One-Liner", also kleine 
Einzeiler-Scripte für die Benutzung auf der Shell. Das geht mit perl und 
awk relativ gut, mit Python geht es aufgrund der notwendigen 
Einrückungen nur mit großen Einschränkungen, oder findet jemand das 
übersichtlich?

1

aws ec2 describe-instances | python3 -c 'import json; import sys; import re; d = json.load(sys.stdin); [[[print(i["InstanceId"]) for t in i["Tags"] if t["Key"] == "Name" and re.search("mein_regex", t["Value"], flags=re.I) ] for i in x["Instances"]] for x in d["Reservations"]]'

(ja, man hätte wahrscheinlich jq nehmen können, mein Problem mit jq 
ist, dass die Syntax beim Versuch es zu verstehen regelmäßig mein Hirn 
sprengt, die awscli Optionen --filter und --query sind leider beide 
case-sensitive).

Was die fehlende Typisierung angeht gibt es Abhilfe:

https://docs.python.org/3/library/typing.html

Ben S. schrieb:
> Ein tab/Klammer kann auch mal durch Unachtsamkeit verloren gehen.

Und wenn man sich daran gewöhnt hat, dass die Formatierung Teil der 
Programmiersprache ist, sorgt man dafür, dass das nicht zu einem Problem 
wird. Zum Beispiel durch den strategisch sinnvollen Einsatz von 
Leerzeilen.

Python ist perfekt für die kleine Skript-Aufgabe zwischendurch. Für 
große Rechenaufgaben nimmt man effiziente Programmiersprachen wie Matlab 
und Fortran.

//.|.\\ schrieb:
> Und woher weiss der Compiler, wo die Klammer hinsoll ???

Ich rede von einer fehlenden Klammer. Da kriegste immerhin eine 
Fehlermeldung. Bei einer fehlenden / falsch gesetzten Einrückumg 
bekommst im Zweifelsfall gar keine Fehlermeldung.

Sheeva P. schrieb:
> PS: Es hat hier einige negative Äußerungen gegeben, die allerdings
> überwiegend zwei Eigenschaften haben: die Autoren haben offensichtlich
> nicht die geringste Erfahrung mit der Sprache

genau wie viele C&P Programmierer die dann Hilfe suchen weil:

Sheeva P. schrieb:
> Die einzige valide Kritik, die ich hier
> gelesen habe, ist die Sache mit dem Whitespace. Und ja, das kann hin und
> wieder genauso nerven wie die Klammerorgien anderer Sprachen

und das ist es wenn Code irgendwie kopiert wird, {} ist immer eindeutig, 
whitespaces bleiben egal ein Block ist klar zu erkennen.

Ben S. schrieb:
> Bei einer fehlenden / falsch gesetzten Einrückumg
> bekommst im Zweifelsfall gar keine Fehlermeldung.

Der Trick besteht darin, im Editor einen Monospace-Font und einen Tab 
mit einer mehr als 1 Zeichen Breite einzustellen. Dann ist das Problem 
deutlich schwerer zu übersehen als eine Klammer.

Wenn man seinen Quelltext in Word mit der Schriftart Comic Sans MS 
schreibt, wird der vergessene Tab natürlich unter Umständen zum Problem, 
weil er genauso klein wie eine Klammer ist. Das ist aber dann einfach 
das falsche Werkzeug für den Anwendungsfall.

Ich bin über die Einrück-Lösung auch nicht maximal glücklich. Aber es 
ist nicht so, als wäre das alles dadurch praktisch unbrauchbar.

Warum jammern bei make eigentlich nicht alle über die Tabs? Oder liegt 
das einfach daran, dass make eher für schlaue Leute gedacht ist?

Hallo,
Walter T. schrieb:
> Warum jammern bei make eigentlich nicht alle über die Tabs?

Ich fand schon immer die Entscheidung, das die Quelltextformatierung 
Teil der Syntax b.z.w. Semantik ist schlecht. Bei (altem) Fortran oder 
make mag das ja noch historisch begründbar sein, aber modernen Sprachen 
wie Python (Entstehungsjahr 1991) sollte das eigentlich keine 
Spracheigenschaft mehr sein.

rhf

Roland F. schrieb:
> aber modernen Sprachen
> wie Python (Entstehungsjahr 1991) sollte das eigentlich keine
> Spracheigenschaft mehr sein.

Gut auf den Punkt gebracht.

Filter schrieb im Beitrag #6489592:
> Python ist super für schnelles Prototyping. Wenn Laufzeit wichtig ist
> eher Matlab oder C++.

Und anschließend darf man den gesamten protogetypten Code auf C++ 
umschreiben? Naja ...

Wodjanoi schrieb:
> Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der
> Source definiert immer einen eindeutigen Compileroutput.

Das gilt zwar auch für UB bei C/C++, aber was der Compiler dabei 
produziert, ist nicht definiert (definiert in dem SInne, daß jemand 
anders als der Compilerbauer das vorhersagen könnte).

Oliver

Karl schrieb:
> Hast du mal einen Performanceǘerglich von Matlab und NumPy gemach? Ich
> glaube nicht, dass da Matlab signifikant besser ist.

Ja, aber nur bei kleinen Gleichungssystemen ( < 100000 Freiheitsgrade). 
Der Unterschied war sehr, sehr deutlich. Da reden wir von < 3 Minuten 
(damals war der Corei7 nagelneu) vs. "ich habe es irgendwann 
abgebrochen". Zumindest bei sparse-Matrizen mit ausgeprägter 
Bandstruktur ist Lapack/Scalapack ein Traum.

Inwieweit mit Python verteiltes Rechnen auf mehreren Kernen geht, habe 
ich dann nicht mehr ausprobiert.

Roland F. schrieb:
> Bei (altem) Fortran oder
> make mag das ja noch historisch begründbar sein

Den Lochkarten wars egal, wo das Loch sass. Und zumindest IBMs 
Mainframes hatten bei Textfiles keinen Zeilenseparator, sondern Zeilen 
fester Länge (typ 80) und ohnehin keine eincodierten TABs.

Arno schrieb:
> Vermutlich gibt es bei numpy ähnliche Fallstricke.

Deswegen lässt man jemanden das machen, der sich damit auskennt.

Ich mag Python. Ich mag auch numpy. Das Preis-Leistungs-Verhältnis ist 
grandios. Aber für number crunching scheint es nicht gemacht.

Nick M. schrieb:
> Hans schrieb:
>> Das ist ja wirklich übel. Ich stelle mir da die Fehlersuche sehr
>> kompliziert vor.
>
> Vor allem, wenn man zur Fehlersuche ein Stück code oder einen Test
> einfügt und man dazu neu formatieren muss. Und danach den test-code
> löschen und wieder neu formatieren. Brilliant!
> Ich pflege meinen Testcode linksbündig zu schreiben, weil ich den
> schneller finde und er sowieso den Tag nicht überleben wird.

Man kann auch nicht mal eben einen Codefetzen hin- und her kopieren oder 
aus dem Netz übernehmen.
Zwar bieten viele IDEs und Texteditoren einfache Mittel zur Steuerung 
der Einrückung, ich halte es aber für fragwürdig zwingend eine sauber 
eingerichtete IDE/Editor und die Kenntnis deren Kniffe und Shortcuts 
vorauszusetzen.

Von dem Thema Whitespaces abgesehen gefällt mir Python ganz gut.
Man kriegt in wenigen Zeilen enorm viel Funktionalität reingequetscht, 
die Sprache bietet viel syntaktischen Zucker für das Handling von 
Containern etc.
Python ist ein wunderbares Werkzeug um mal eben was zu skripten oder zu 
automatisieren.

Bei größeren Projekten stört mich die fehlende Typisierung sowie dass 
jeder auf so gut wie alles zugreifen kann.
Das kann man zwar mit Disziplin und guter SW-Planung einigermaßen 
ausgleichen, es beißt sich aber m.M.n. mit dem Whitespace-Konzept wo 
(Formatierungs-)Diszplin explizit erzwungen wird.
Ja was denn nun? Freiheiten oder Zwang zum sauberen Arbeiten?

Aber bei meinen Bastelskripten störts mich nicht, da bin ich froh um die 
Freiheiten (die man in C paradoxerweise zurecht kritisiert).

Qt macht mit Python definitiv mehr Spaß als mit C++ ;-)

Nick M. schrieb:
> Arno Dübel schrieb:
>> ich sauf mir jetzt ein
>
> Wenn man nix anderes kann ...

Auch das will gelernt sein.
Hast du schon mal nen Anfänger saufen sehen? Schrecklich!

Ich bin ja auch eher Fan von C/C# (allerdings auch kein Profi) aber 
Python hat schon seine Berechtigung, auch wenn das manche hier nicht in 
den Hals bekommen, die würden am liebsten alles außer ASM und evtl. C 
verbieten.

Es ist vorallem interessant für Leute die zwar keine Tech-Noobs sind 
allerdings auch keine Informatiker, also andere Ingenieure und 
Wissenschaftler.
Deshalb gibt es eben eine Menge an bereits vorhandener Software und 
unterstüzung für Schnittstellen, wie zB. GPIB usw.

Python ist sehr geeignet für die ganze "Zwischendurch-SW" also zB. Daten 
von Messgeräten/IO-Karten/Netzwerk einlesen und damit Berechnungen 
durchführen/loggen usw. ohne das ein Monatelanges Projekt daraus wird.
Eben Anwendungen wo weder der Code noch die Geschwindigkeit/Effizienz 
vorderrangig ist sondern das damit erreichte Ergebnis, eben zB. in 
Forschungsprojekten wo man keine Wochen für eine im Endeffekt sowieso 
nebensächliche Messung verschwenden möchte.

Nick M. schrieb:
> Geht mit z.B. Tcl genauso. Incl. LXI-Server und die Daten für GnuPlot
> aufbereiten und damit darstellen..

Und nicht nur damit sondern mit mindestens nem Dutzend anderer 
Skriptsprachen.

Aber scheinbar hat Python etwas was die Leute wollen, Tcl nicht.
Und nu?

Ben S. schrieb:
> Sheeva P. schrieb:
>> Die Lesbarkeit von Code hängt allerdings nicht nur von der Formatierung
>> ab.
>
> Doch, fast immer.

Und Du redest von Noobs, sogar von Softwareentwicklung? Das kann ich gar 
nicht glauben. Ein gestandener Softwareentwickler hätte meine -- mit 
großem Bedacht eingefügte  -- Formulierung "nicht NUR" gelesen und 
verstanden.

> Sheeva P. schrieb:
>> Das ist, wie so vieles, reine Übungssache. Jedenfalls erzwingt diese
>> Eigenschaft eine saubere Blockeinrückung, und mir ist unverständlich,
>> wie das die Lesbarkeit verschlechtern sollte, das ist ja völlig abstrus.
>
> Ach, jetzt soll ich eine furchtbare Formatierungseigenschaft üben, bis
> ich diese kann?

Pardon, aber was Du machst oder nicht, ist mir ziemlich gleichgültig. 
Ich habe nur von meinen Erfahrungen mit Python geredet, also denen, die 
Du offensichtlich nicht hast und auch nicht haben willst. Von mir aus, 
na und? Warum gehst Du hier bloß so hoch, wenn jemand von seinen 
positiven Erfahrungen mit einer Sprache erzählt, die Du offensichtlich 
nicht leiden kannst? Geh' mal 'ne Runde an die frische Luft, das ist gut 
für die Gesundheit und das Gemüt.

> Ich sehe keinen praktischen Grund auf einem mikrocontroller python
> einzusetzen., bitte nenne mir einen.

Weil man's kann. Weil die Software womöglich sehr häufig angepaßt und 
verändert werden muß und Entwicklungszeit darum eine große Rolle spielt. 
Weil andere Leute womöglich keine Profientwickler sind und trotzdem 
Zugang zu Elektronikspielzeug bekommen sollen -- da haben die 
Arduino-Jungs sogar ein ziemlich großes Projekt draus gemacht.

Abgesehen davon war die Frage des TO nicht auf Mikrocontroller, sondern 
nur auf die Gründe für den Erfolg von Python gerichtet. Daß man es auch 
auf Mikrocontrollern nutzen kann, war lediglich eine Randbemerkung. Aber 
spannend, daß die Armada der Mikrocon-Trolle jetzt darauf anspringt wie 
ein Hund auf seinen Knochen.

Markus M. schrieb:
> [...] oder findet jemand das übersichtlich?
>
>

1

> aws ec2 describe-instances | python3 -c 'import json; import sys; import 

2

> re; d = json.load(sys.stdin); [[[print(i["InstanceId"]) for t in 

3

> i["Tags"] if t["Key"] == "Name" and re.search("mein_regex", t["Value"], 

4

> flags=re.I) ] for i in x["Instances"]] for x in d["Reservations"]]'

5

>

Nein, natürlich nicht. Aber versuch' das mal in C, C++, oder Java... ;-)

> Was die fehlende Typisierung angeht gibt es Abhilfe:
>
> https://docs.python.org/3/library/typing.html

Sie fehlt ja nicht, sie ist nur an den Value gebunden statt ans Symbol. 
Das ist nicht wie in PHP oder Perl, wo 12 / '4' tatsächlich 3 ergibt -- 
Python und Ruby werfen dort korrekterweise eine Exception. Die Type 
Hints in Python sind super, werden aber vom Interpreter nicht 
durchgesetzt; das muß man vorher mit einem externen Tool prüfen.

Walter T. schrieb:
> Python ist perfekt für die kleine Skript-Aufgabe zwischendurch. Für
> große Rechenaufgaben nimmt man effiziente Programmiersprachen wie Matlab
> und Fortran.

Da ist es aber wirklich komisch, daß Python gerade dort besonders 
beliebt ist, wo es um die größten Datenmengen geht: Big Data, Data 
Science, Machine und Deep Learning... übrigens: Python-Frameworks wie 
numpy, scipy und Pandas benutzen intern oft genau dieselben 
Numbercrunching-Bibliotheken wie Matlab & Co... ;-)

Roland F. schrieb:
> Ich fand schon immer die Entscheidung, das die Quelltextformatierung
> Teil der Syntax b.z.w. Semantik ist schlecht. Bei (altem) Fortran oder
> make mag das ja noch historisch begründbar sein, aber modernen Sprachen
> wie Python (Entstehungsjahr 1991) sollte das eigentlich keine
> Spracheigenschaft mehr sein.

Das war eine bewußte Entscheidung, um die Lesbarkeit zu erhöhen und die 
Entwickler zu zwingen, sauberen Code zu schreiben. Und das funktioniert 
tatsächlich ziemlich gut.

Wodjanoi schrieb:
> Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der
> Source definiert immer einen eindeutigen Compileroutput. Natürlich
> können zwei verschiedene Compiler (anderer Hersteller, Revisionen)
> unterschiedliche Outputs erzeugen. Vielleicht ein plus von Python das
> weniger Interpreter-Hersteller und -varianten kennt als C in seiner fast
> 48-jährigen Geschichte.

Für Python fallen mir als Interpreter schon vier ein -- die 
Referenzimplementierung CPython, der performanceoptimierte Pypy, das in 
Java geschriebene Jython und das in C# geschriebene IronPython. Hinzu 
kommen mindestens zwei Compiler, nuitka und einer, dessen Name mir 
gerade entfallen ist.

Ich gehe jetzt nicht auf alles ein, was seit meinem letzten Post 
geschrieben wurde. Aber auch mich überzeugt das Konzept "Strukturierung 
mit Whitespace" nicht. Das erwarte ich eher in einer Joke-Sprache wie 
eben "Whitespace" zu finden, als in einer ernstgemeinten 
Programmiersprache.

Der Vergleich mit C (oder anderen Sprachen, die Klammern verwenden) 
hinkt dahingehend, daß man alle diese Sprachen automatisch einrücken 
lassen kann. Was gerade beim Refaktoring oder kopieren von Code zwischen 
Projekten enorm praktisch ist. Vergessene Klammern kann man dadurch auch 
leicht finden, weil man nach der Re-Indentierung die Code-Struktur so 
sieht, wie der Compiler. Bei Python hat man diese Möglichkeit nicht. 
Entweder die Indentierung (und damit Struktur) stimmt oder sie stimmt 
nicht.

Der Hauptgrund, warum ich Python bis jetzt nicht angefaßt habe, ist aber 
ein anderer: es gibt schlicht keine Lücke, die Python bei mir füllen 
könnte. Was andere hier anscheinend gerne mit Python machen, mache ich 
mit Perl. Geschwindigkeit war nie ein Thema und instabile Perl-Programme 
habe ich auch noch nie gehabt.

Ja, Perl ist extrem ausdrucksstark, fast wie eine natürliche Sprache (da 
kommt natürlich Larrys Background als Linguist durch). Man kann 
dadurch in Perl extrem gut lesbaren Code schreiben. Andererseits kann 
man auch extremes Kauderwelsch produzieren. Aber das kann man 
bekanntlich in jeder Programmiersprache. Persönlich mag ich Freiheit 
lieber als Zwang. Auch wenn es der Zwang zu einem besonderen 
Programmierstil ist, den jemand (oder meinetwegen auch die 
Allgemeinheit) als besonders lesbar ansieht.

Hans schrieb:
> W.S. schrieb:
>> Aber hier bei Python haben wir stattdessen
>> unterschiedliche Anzahl von 'white space' Zeichen!
>>
>> Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt?
>> Nein, nicht mit mir.
>
> Das ist ja wirklich übel. Ich stelle mir da die Fehlersuche sehr
> kompliziert vor. Mir war nicht klar, dass es noch moderne
> Programmiersprachen mit nennenswerter Verbreitung dieser Art gibt.

Das ist gar nicht übel. Der Interpreter erkennt das, während er den 
Quellcode in Bytecode übersetzt, und bricht mit einer eindeutigen 
Fehlermeldung ab. WS hat mal wieder keine Ahnung, was er faselt.

DoS schrieb:
> Mega grottig ist die "GUI-Fähigkeit" die  ist auf dem Niveau von 1988.

Du meinst die Anbindungen an Qt, WxWidgets, GTK, und die GUI-Toolkits 
von Java und C#?

> Wenn ich das mit VisualBasic aus den 1990ern vergleiche, war das damals
> besser gelöst. Nur: damals gab es halbwegs genormte Monitore. Heute muss
> eine GUI dynamisch skalieren. Da kann es nicht sein, dass Buttons und
> andere Grafikelemente per Pixel positioniert und definiert werden und
> das Look and Feel des Betriebssystem nicht wiederspiegelt.

Das Ausrichten kann sogar das in Python standardmäßig enthaltene Tk...

Nick M. schrieb:
> A. K. schrieb:
>> Python ist sehr geeignet für die ganze "Zwischendurch-SW" also zB. Daten
>> von Messgeräten/IO-Karten/Netzwerk einlesen und damit Berechnungen
>> durchführen/loggen usw. ohne das ein Monatelanges Projekt daraus wird.
>
> Geht mit z.B. Tcl genauso. Incl. LXI-Server und die Daten für GnuPlot
> aufbereiten und damit darstellen..

Dann zeig' mir doch bitte mal etwas in Tcl, das auch nur ansatzweise mit 
numpy, Scipy, Pandas, Bokeh, Seaborn, ggplot oder geoplotlib mithalten 
kann. Danke.

Auf die Gefahr hin, mich zu wiederholen: es gibt gute Gründe dafür, daß 
Python vor allem dort besonders beliebt ist, wo Leute professionell mit 
riesigen Datenmengen umgehen (müssen), etwa Data Science, Big Data und 
Machine Learning... Das paßt (für die, die es noch nicht mitbekommen 
haben) natürlich auch nicht zu der hier häufiger vorgetragenen 
Behauptung, Python sei langsam oder nicht für große Projekte geeignet.

Bastler schrieb:
> Den professionellen, kommerziellen Bereich mag ich jetzt nicht
> beurteilen. Aber ich denke im privaten Hobbybereich und auch in
> Schule/Ausbildung hat der Raspberry maßgeblich zur Popularität von
> Python beigetragen

Es sind zwar bislang weltweit etwa 30 Millionen RasPis verkauft worden, 
trotzdem ist das ein ziemliches Nischenprodukt für... spezielle Leute. 
Und der Siegeszug von Python ist schon viel älter als die RasPis... ;-)

Axel S. schrieb:
> Ich gehe jetzt nicht auf alles ein, was seit meinem letzten Post
> geschrieben wurde. Aber auch mich überzeugt das Konzept "Strukturierung
> mit Whitespace" nicht.
> [...]
> Der Hauptgrund, warum ich Python bis jetzt nicht angefaßt habe,

Es ist schon seltsam, daß sich hier vor allem jene über die 
Whitespace-Geschichte echauffieren, die nur wenig bis gar keine 
Python-Erfahrung haben.

> Ja, Perl ist extrem ausdrucksstark, fast wie eine natürliche Sprache (da
> kommt natürlich Larrys Background als Linguist durch). Man *kann*
> dadurch in Perl extrem gut lesbaren Code schreiben.

Das gilt in noch höherem Maße für Python, und... sorry, aber einer 
meiner Gründe, nach über dreizehn Jahren von meiner damaligen 
Standard-Skriptsprache Perl zu Python zu wechseln, waren auch Pythons 
bessere Lesbarkeit, Ausdrucksstärke, und Performanz.

W.S. schrieb:
> Rolf M. schrieb:
>> Das wird immer wieder als das große "Problem" aufgetan. Irgendwie
>> verstehe ich das nicht. Es erzwingt halt vernünftige Einrückung.
>
> Es IST ein großes Problem, oder besser gesagt eine große Sauerei. Man
> macht sowas nicht in einer Programmiersprache.

Doch, macht man. Python macht das so und hat sich auch deswegen zur mit 
Abstand beliebtesten und verbreitetsten Skriptsprache entwickelt. Wie 
blöd, daß der Rest dieser schönen Welt auf Deine Ansichten pfeift...

Egon D. schrieb:
> Das ist schlecht, denn die gesprochene Sprache kennt
> die Sprachmelodie als Kanal für die Meta-Daten, die
> geschriebene natürliche Sprache kennt die Interpunktion,
> und die allermeisten Programmiersprachen kennen
> Schlüsselworte oder Sonderzeichen dafür. Nur Python
> kennt nix.

Aber ja doch. Einrückungen. Meine Güte, ist das wirklich so schwer?

Irgendwer schrieb:
> Sheeva P. schrieb:
>> Es ist schon seltsam, daß sich hier vor allem jene über die
>> Whitespace-Geschichte echauffieren, die nur wenig bis gar keine
>> Python-Erfahrung haben.
>
> Ich würde noch weiter gehen und behaupten, die meisten Kritiker (hier)
> haben noch nie ernsthaft programmiert und kennen maximale vielleicht
> eine oder zwei Programmiersprachen.

Das deckt sich mit meinen Vermutungen. ;-)

Egon D. schrieb:
> Du verdrehst den Sinn der gemachten Aussagen. Niemand
> hat gefordert, dass man nicht einrücken solle. Die
> Aussage war nur: Der VERZICHT auf "Interpunktion" (d.h.
> druckbare Zeichen für die Blockstruktur) ist schlecht.

Python hat doch Interpunktion, mindestens den Doppelpunkt am Ende einer 
Zeile, die einen neuen Block einleitet:

1

if 1 < 2:

2

  print('yes')

Egon D. schrieb:
> Nein -- umgekehrt: Es wäre logisch, wenn der Computer die
> Einrückung automatisch aus der Klammerung erzeugen würde
> (oder -- alternativ -- die Klammer selbst setzt, wenn ich
> einrücke).

Dafür gibt es ja inzwischen für die meisten Programmiersprachen 
automatische Code-Formatierer wie prettier, clang-format etc. Seitdem 
ich diese für alles Mögliche einsetze, habe ich viel mehr Zeit, mir 
inhaltlich um den Code, den ich schreibe, Gedanken zu machen: einmal 
Speichern mit Ctrl-S und der Code ist hübsch.

Egon D. schrieb:
> Auch der Morsecode beschränkt sich nicht auf "Ton" und
> "Pause", obwohl das theoretisch ausreichend wäre, sondern
> verwendet "kurzer Ton", "langer Ton" und "Pause".

Dann aber bei dem Beispiel bitte nicht vergessen, dass es neben den 
beiden Tonlängen (kurz/lang) auch drei verschiedene Pausenlängen braucht 
(zwischen Tönen, zwischen Buchstaben und zwischen Wörtern).

Max M. schrieb:
> Python hat doch Interpunktion, mindestens den Doppelpunkt am Ende einer
> Zeile, die einen neuen Block einleitet:

In Verbindung mit einem anständigen Editor gibt es sogar in Python ein 
Schlüsselwort, das man zur Beendigung eines Blocks und automatischen 
Ausrückung mißbrauchen kann: pass. Das macht den Code zwar häßlich und 
schlechter lesbar, ist in bestimmten Fällen allerdings durchaus 
hilfreich...

W.S. schrieb:
> Rolf M. schrieb:
>> Das wird immer wieder als das große "Problem" aufgetan. Irgendwie
>> verstehe ich das nicht. Es erzwingt halt vernünftige Einrückung.
>
> Es IST ein großes Problem,

Für mich ist es das nicht. Du konntest bisher auch leider nicht 
darlegen, warum das ein Problem sein soll, außer weil du dann eben nicht 
mehr kreuz und quer einrücken darfst.

> oder besser gesagt eine große Sauerei. Man macht sowas nicht in einer
> Programmiersprache.

Bei dir und vielen anderen hier im Thread fällt mir auf, dass ihr sagt: 
"Ich kann das nicht leiden", "das kommt mir nicht ins Haus", "das macht 
man nicht", "das ist ja ganz furchtbar", aber ohne jegliche Begründung.
Nur sehr wenige nennen überhaupt konkrete Gründe, die auch durchaus 
plausibel, aber für mich nicht unbedingt ein k.o.-Kriterum sind.

Egon D. schrieb:
> Naja, vor allem finde ich Rolfs Verteidigung arg
> willkürlich.
>
> Wenn ich C kritisiere, dann ist jeder Zwang des Teufels,
> und Freiheit das oberste Gebot.
> Wenn man Python kritisiert, ist plötzlich der Zwang
> zu vernünftiger Einrückung richtig?!

Wo hab ich denn sowas behaupet? In C gibt es auch Zwänge, wie in jeder 
Programmiersprache. Und auch in C rücke ich trotz fehlenem Zwang 
ordentlich ein.

Egon D. schrieb:
> und die allermeisten Programmiersprachen kennen
> Schlüsselworte oder Sonderzeichen dafür. Nur Python
> kennt nix.

Das Leerzeichen ist in der Hinsicht wie die 0 in der Mathematik. Die ist 
auch nicht "nix", denn eine 0 mehr oder weniger am Ende des Kontostandes 
macht einen riesen Unterschied.

Egon D. schrieb:
> Er hat daraus -- m.E. zu Unrecht -- gefolgert, es dürfe
> nur genau EINE Methode geben, die Blockstruktur deutlich
> zu machen, und das müsse eben die Einrückung sein.

Dass das sein müsse, hat er nicht gesagt, nur dass es die logische 
Konsequenz wäre. Und die ist es ja auch. Als Mensch bin ich auf die 
Einrückung angewiesen. Für den Interpreter kann ich mir aussuchen, was 
er nimmt. Da wäre doch tatsächlich die logische Konsequenz, die dort 
auch einzusetzen, statt für den nochmal ein zusätzliches redundantes 
Element einzuführen, das eben zu dem Risiko von Inkonsistenzen zwischen 
den beiden führen kann.

Ben S. schrieb:
> Ach, jetzt soll ich eine furchtbare Formatierungseigenschaft üben, bis
> ich diese kann?

Saubere Einrückung ist für dich eine "furchtbare 
Formatierungseigenschaft"? Eigentlich sollte sie eine 
Selbstverständlichkeit sein.

Klaus H. schrieb:
> Bei C/C++ eine Klammer falsch gesetzt? Pech gehabt, stundenlange
> Fehlersuche.

Ja, vor allem, wenn es richtig eingerückt ist und eben nur die Klammer 
falsch ist. Ich schaue mir die Einrückung an und denke: "passt", und den 
Compiler interessiert die aber gar nicht, und er macht was ganz anderes 
draus. Solche Fälle hatte ich in C bei Fremdcode schon, in Python könnte 
das gar nicht passieren.

Wodjanoi schrieb:
> Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der
> Source definiert immer einen eindeutigen Compileroutput.

Bei undefiniertem Verhalten nicht. Das ist - wie der Name schon sagt - 
gar nichts definiert. Und das bedeutet auch, dass der Compiler durchaus 
auch würfeln dürfte. Die meisten tun das allerdings nicht, aber an 
vielen Stellen kümmern sie sich einfach nicht darum, was dort dann 
passiert.

Klaus schrieb:
> Ich habe gültigen Code geschrieben. Der Sprachstandard und der Compiler
> haben daraus undefiniertes Verhalten gemacht.

Das ist aber eine merkwürdige Ansicht. Du hast Code geschrieben, der 
gegen den Standard verstößt, und nun erklärst du ihn zu gültigem Code 
und beanstandest, dass der Standard ihn ungültig mache. Das klingt fast, 
wie wenn sich jemand nach eine Wahlniederlage einfach selbst zum 
Gewinner erklärt.

Nick M. schrieb:
> Vor allem, wenn man zur Fehlersuche ein Stück code oder einen Test
> einfügt und man dazu neu formatieren muss. Und danach den test-code
> löschen und wieder neu formatieren. Brilliant!
> Ich pflege meinen Testcode linksbündig zu schreiben, weil ich den
> schneller finde und er sowieso den Tag nicht überleben wird.

Ja, das ist eine Sache, die mich tatsächlich auch stört, weil ich das 
von C++ auch gewöhnt bin, das so zu tun. Wobei es etwas Gewöhnungssache 
ist. Bevor ich den Code einchecke, diffe ich ihn sowieso nochmal gegen 
die ursprügnliche Version. Da sieht man den eingefügten Code auch sofort 
und kann ihn dann noch entfernen.

LOL schrieb:
> Die Behauptung ist doch, dass
> Pseudocode A:
> res = 0
> for i in 1..2:
>    res = res+1
>    res = res+1
>
> Pseudocode B:res = 0
> for i in 1..2:
>    res = res+1
> res = res+1
>
> in python kein Fehler ist, aber komplett andere Ergebnisse (Fall A: 4,
> Fall B: 3) liefert - in den "klammerbasierten" Sprachen aber ein Fehler
> wäre, weil dann irgendwo eine Klammer vergessen wurde.

Die gleichen Schleifen wären in C so auch kein Fehler, aber hätten das 
selbe Ergebnis, obwohl man beim Überfliegen des Code auf Grund der 
Einrückung etwas unterschiedliches erwarten könnte.

W.S. schrieb:
> Das ist eben die Sichtweise von C. Und ich kann solche Zusammenziehungen
> üerhaupt NICHT leiden:
> for (int i = 0; ...
>
> anständigerweise würde man es so schreiben:
> int i;
> ...
> for (i = 0; ...

Das ist überhaupt nicht anständig. i ist der Schleifenzähler. Er ist nur 
für die Schleife da und sollte deshalb logischerweise auch nur in der 
Schleife definiert sein. Warum soll man die Schleife und die Definiton 
des dazugehörigen Zählers auseinanderreißen? Ich sehe da nun wirklich 
überhaupt keinen Vorteil darin.

>> Python macht daraus ein einfaches:
>> for abc in xyz:
>
> Das wiederum ist extrem unverständlich und auch genau so nicht
> erwünscht.

Verständlicher und vor allem kompakter geht es nicht.

> Der Grund ist, daß man in einer for-Anweisung ja auch die Möglichkeit haben
> will, dediziert auf das vorherige oder nächste Element zugreifen zu können.

Ja, das ist tatsächlich unschön. In Python kann man das notfalls noch so 
machen:

1

for index, abc in enumerate(xyz):

Dann kann man per abc direkt auf das aktuelle Element zugreifen, aber 
auch den index nutzen, um auf benachbarte Elemente zugreifen. Ist 
zugegebenermaßen weniger elegant, aber immer noch recht klar und 
verständlich.

> Und die Unverständlichkeit rührt aus der Mengenalgebra her:
> if element in menge then tuwasdamit;
> konkret:
> if (Ch in ['0'..'9','.','-','+']) then ...
>
> aber genau DAS scheint mir bei Python eben nicht gemeint zu sein.

Exakt das gibt es in Python auch.

1

if e in M:

Bedeutet: Für jedes Element in Menge M prüfe, ob es e entspricht. Oder 
anders ausgedrückt: Prüfe, ob e in M enthalten ist. Falls ja, tue 
folgendes.

1

for e in M:

Bedeutet: Für jedes Element e in Menge M tue folgendes.
Was ist daran unverständlich?

>> ... wobei in den meisten Fällen die Iterationsvariable ganz wegfällt,
>> weil xyz selbst eine iterierbare Klasse ist und "selbst weiß, wie man
>> sich aufzählt"
>
> Nö. Eine Objektklasse kann sich nicht selbst aufzählen.

In Python schon, da Klassen selbst wiederum Objekte sind und man auch 
über alle Elemente eines Objekts iterieren kann. Aber es war ganz 
offensichtlich gemeint, dass die Klasse weiß, wie eine Instanz sich 
aufzählt.

Klaus schrieb:
> Aber es ging mir garnicht um die guten/schlechten Punkte in C.
> Mir ging es darum, ob Python mehr konkrete Vorgaben für die
> Interpreter/Compilerbauer macht als C, damit weniger undefiniertes
> Verhalten auftritt.

Ich würde sagen, dass die Sprachdefinition allgemein schon viel weniger 
Raum dafür lässt. Es gibt z.B. keine Pointer, daher auch keine 
undefinierten Zugriffe darauf. int ist unbegrenzt, d.h. es gibt keine 
Integer-Promotion und es kann auch keine Überläufe geben. Ich würde 
sagen, dass ist bei interpretierten Sprachen meistens so. Da Performance 
sowieso nicht im Vordergrund steht, kann man auch mehr Checks einbauen, 
die undefiniertes Verhalten abfangen.
Allerdings kann man von Python aus ja auch Module nutzen, die in C oder 
anderen Sprachen implementiert sind. In dem Fall kann das natürlich 
anders aussehen.

>> Das klingt fast, wie wenn sich jemand nach eine Wahlniederlage einfach selbst
> zum Gewinner erklärt.
> Für solche provozierenden Thesen habe ich keine Zeit.
> Muss Golf spielen gehen... :-)

:)

Wo wir wieder bei einer mit religiösem Eifer geführten Diskussion über 
(Script-)programmiersprachen wären. Warum kann man nicht einfach mal 
akzeptieren, das andere eben eine eigene Meinung habe. Stattdessen wird 
die eigene Position zur einzig Wahren verklärt.

Ich mag Python, ich entwickle damit unser HIL Testsystem, was mit 
integrierter automatischer C nach Python Konvertierung zum Einbinden 
externen Programmbibliotheken daher kommt, genauso wie ich damit vor 
Jahren beim DWD innerhalb von Sekunden große Satellitenkarten (numpy, 
matplotlib) berechnet/erstellt habe. Ist einfach ne tolle Sprache und 
wenn man erstmal das Konzept "alles ist eine Instanz" verstanden hat, 
dann macht es erst richtig Spaß.

Und wenn ich halt mal was in Lua, Groovy oder auch Perl machen muss dann 
bekomme ich auch nicht gleich einen roten Kopf.

Nick M. schrieb:
> Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf
> rumhacken kann: PL/SQL

Wenns danach geht: IBMs REXX. Eine Script-Sprache ohne Keywords:
 IF IF = THEN THEN
   DO
     END = NEAR
   END

Nick M. schrieb:
> Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf
> rumhacken kann: PL/SQL

Im Zuge der Aussöhnung eigentlich eine gute Idee.
Suchen wir mal ein Feindbild auf dem alle gemeinsam rumhacken können.

Ich werf mal, aus aktuellem Anlass, JavaScript in die Runde.
In der Backend-Entwicklung ein Graus, vor allem wenn man die 
Ausdrucksstärke von Python gewohnt ist.
Beim Frontend, gemischt mit jQuery und MaterializeCSS eine absolute 
Katastrophe.

W.S. schrieb:
> ichschreibejaauchnichtallesohnezwischenräumeweil
> esindiesemfallekeinenblockzumarkierengibt.

In FORTRAN geht das in Ordnung, Leerzeichen sind optional.

dee schrieb:
> Ich weiß gar nicht warum hier gestritten wird. Offensichtlich
> funktioniert Python trotz oder gerade wegen dieser Eigenheit sehr gut.
> Wer es nicht mag soll es nicht benutzen - muss dann aber auch nicht
> behaupten, dass Whitespace-Semantik falsch oder schlecht sei.

Und wenn ich Python grundsätzlich ganz gern mag, mit Klammern oder 
Keywords anstelle Whitespaces zur Blockkennzeichnung aber noch besser 
finden würde?

(prx) A. K. schrieb:
> Nick M. schrieb:
>> Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf
>> rumhacken kann: PL/SQL
>
> Wenns danach geht: IBMs REXX. Eine Script-Sprache ohne Keywords

Eigentlich war ARexx auf dem Amiga ganz cool. Fast alle GUI-Programme 
hatten eine zusätzliche Script-Schnittstelle. Das hätte ich sehr oft 
gerne zurück.

Perl (also perl 5) ist zwar dafür berüchtigt dass evtl in 5 Jahre kein 
Mensch mehr den Code lesen kann. Bei vielen Alternativen ist es hingegen 
garantiert dass in 5 Jahren kein Interpreter den Code mehr lesen kann :)

Eben weil an Perl schon lang genug gearbeitet wurde dass der Drang, alle 
Jahre mutwillig am Sprachkern herumzudoktern, inzwischen vergangen ist.

Hi Leute,

das es bei einer Programmiersprache hier immer hoch her geht ist klar 
....
Vor vielen Jahren (ca. 15) hat mich die Formatierung auch erstmal 
genervt, da hab ich noch viel mit Perl gemacht. Aber die Zeit bleibt nun 
mal nicht stehen und gerade für Python gibt es sehr viele gute Libs die 
auch einfach eingebunden werden können. Seit geraumer Zeit verwende ich 
auch meist Python. Für eine GUI z.B. PyQt5.
Klar, mit einem "vi" tut man sich da keinen Gefallen... Also, für 
Python-Projekte die Pycharm-IDE und für Java dann Netbeans oder 
Eclipse...

my two cents ...

W.S. schrieb:
> Rolf M. schrieb:
>> Du konntest bisher auch leider nicht
>> darlegen, warum das ein Problem sein soll, außer weil du dann eben nicht
>> mehr kreuz und quer einrücken darfst.
>
> Ich habe überhaupt nicht von kreuz und quer einrücken geschrieben.

Du hast es aber als Katastrophe dargestellt, dass es nur mit 
vernünftiger Einrückung geht. Daraus habe ich geschlussfolgert, dass du 
bevorzugst, kreuz und quer einzurücken, denn wenn du das nicht tust, 
könnte es dir ja wie mir egal sein.

> Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen
> aus druckbaren Zeichen bestehen, eben weil es in Wirklichkeit keine
> Programmiersprachen, sondern Programmier-Schrift-Sprachen sind.

Warum? Bei manchen Programmiersprachen (u.a. so ziemlich alle 
Assembler-Varianten) kann man auch Newlines nicht einfach setzen wo man 
will. Warum dürfen Elemente, die man zur optischen Gliederung des Code 
nutzt, nicht gleichzeitig auch zur logischen Gliederung dienen? Und 
nein, ein "weil man das halt nicht macht" reicht mir nicht.

> Niemand spricht eine solche Sprache, sie werden alle immerzu nur
> geschrieben und dazu braucht es Zeichen. Nicht abgezählte Zwischenräume,
> sondern Zeichen bzw. Wörter.

Auch für diese Aussage sehe ich keine Begründung. Warum braucht es das?

> Die Zwischenräume gibt es üblicherweise nur dazu, zwischen den
> Zeichen/Wörtern zu trennen.

Das sieht für mich nach einer willkürliche Festlegung ohne technischen 
Grund aus.

> ichschreibejaauchnichtallesohnezwischenräumeweil
> esindiesemfallekeinenblockzumarkierengibt.
>
> Eine Programmiersprache, die das Maß von Zwischenräumen ab Zeilenbeginn
> zu einem Sprachelement macht, verstößt damit frontal gegen obigen
> Grundsatz. Das ist dann nicht mehr formatfrei und es öffnet Fehlern und
> Mißverständnissen Tür und Tor. Beispiel space vor tab, was man selbst
> durch intensives Draufgucken nicht unterscheiden kann.

Wie schon gesagt: Die zu mischen, ist so oder so eine blöde Idee. Und 
Python weist einen per Fehlermeldung darauf hin. Mein Editor übrigens 
auch.

> Vielleicht ist dieses Einrücken programmiertechnisch einfacher beim
> Schreiben des Python-Interpreters zu machen, als wenn man sich im
> Interpreter sowas wie {  } begin end merken müßte. Aber das bedeutet,
> die Sache vom Standpunkt der Programmierers des Interpreters zu sehen
> und nicht vom Standpunkt des Benutzers der Programmiersprache.

Ich glaube eher, dass es für den Interpreter schwieriger ist und dass es 
gemacht wurde, weil es für den Benutzer einfacher ist.

DoS schrieb:
> Kam ha auch von Microsoft, und die hatten ein gewisses Interesse an
> Windows als BS. Gibt es überhaupt was von Microsoft, das für Linux ist
> (außer ein Migrationstool Linux-> Windows)?

Inzwischen so einiges. Und der überwiegende Teil der Microsoft-Cloud 
läuft unter Linux. Auch Microsoft musste einsehen, dass da kein Weg mehr 
dran vorbei führt. Vielleicht liegt's aber auch nur daran, dass Bill 
Gates nicht mehr so involviert ist. Der hatte Linux immer ziemlich auf 
dem Kieker.

Ingo D. schrieb:
> Klar, mit einem "vi" tut man sich da keinen Gefallen...

Ja stimmt, besser vim mit YCM und noch dem einen oder anderen weiteren 
Plugin.

Manche Editoren können halbautomatisch anhand der Klammerebenen 
einrücken (zB emacs) - das entlastet den Kopf und bietet auch direkt 
eine Art fortwährenden Syntaxcheck. Und ist mit "klammerarmen" Sprachen 
nicht so gut möglich...

Wenn Whitespace nichts ist - warum beschwert ihr euch gerade etliche 
Beiträge lang darüber?

W.S. schrieb:
> 1. Einrückungen sind zum gefälligen optischen Bild, wenn man sich die
> Quelle anschaut.

Es gibt ziemlich viele Dinge in Programmiersprachen, die eigentlich nur 
für die gefällige Optik da sind, aber trotzdem semantische Bedeutung 
haben. Zum Beispiel Variablennamen. Den Rechner interessiert am Ende nur 
die Adresse, auf die er zugreifen muss.

Klaus schrieb:
> Eine schlechte Programmiersprache wäre für mich eine,
> auf die man sich nicht verlassen kann. Erzeugt jedesmal andere
> Ausgaben...

Auch das lässt sich finden:
http://p-nand-q.com/programming/languages/java2k/

Man dieser Thread ist ja schon fast bestes Comedy Gold.

Zum Thema Einrückung kann man eigentlich nur folgendes sagen:
Wenn ihr nicht sowieso schon eine gute IDE oder einen guten Editor 
benutzt, dann ist jetzt die Chance dies zu tun.
BSP VSCode:
Mit dem Python Plugin wird sofort ein Fehler angezeigt wenn man Tabs und 
Leerzeichen mischt, aber in den Einstellungen kann man auch gleich 
festlegen das beim druck auf die Tab-Taste einfach die vorgegebene 
Anzahl Spaces eingefügt (Standard 4).

Auch das Plugin Pylance für VSCode ist sehr cool, den man kann live 
Typechecking bekommen (kein mypy Aufruf unbedingt mehr notwendig, ich 
benutzt es aber trotzdem noch), ergo während ich schreibe bekomme ich 
die Mitteilung, ob ich mir sicher bin eine Liste aus Integern an eine 
Funktion die einen String erwartet zu übergeben. (Funktioniert natürlich 
nur wenn man Code mit type hints benutzt, aber einige Bibliotheken tun 
dies, und auch der eigene Code profitiert davon.)
Das macht zwar Python nicht typsicher, hilft einen aber den typischen 
"Montags morgen vor dem ersten Kaffee" Code zu überprüfen.

Irgendwer schrieb:
> Aber einem Menschen ist es nicht egal. In der Wahrnehmungspsychologie
> ist es von oben bis unten durchgeforscht: Dein Hirn nimmt eingerückte
> Strukturen deutlich schneller und einfacher wahr als verschachtelte
> Klammern. Unsere ganze Schriftkultur besteht aus Blöcken und
> Einrückungen.

Richtig. Man kann die Sache ja mal von einer... höheren Ebene aus 
betrachten: wozu dienen in Sprachen wie Java, C, C++ und C# eigentlich 
die Klammern, in Pascal BEGIN und END und in Ruby das end? Genau: sie 
dienen ausschließlich dem Computer, damit er das Ende eines Blocks 
erkennen kann. Whitespace ist hier für den Compiler also völlig 
überflüssig, der Compiler braucht ihn nicht -- für den Compiler ist es 
gleichgültig, ob ich

1

2

for(int i = 0; i < 20; ++i) {

3

    tuwas(i);

4

}

schreibe oder

1

2

for(int i=0;i<20;++i){tuwas(i);}

Nur hinter der Deklaration der Variablen i ist ein Whitespace für den 
Compiler notwendig, damit er die beiden Token voneinander unterscheiden 
kann.

Die Whitespaces dagegen, die jeder gute Entwickler trotzdem macht, 
dienen hingegen dem Menschen, indem sie die Les- und Wartbarkeit des 
Code deutlich verbessern.

Da war es eine naheliegende und sinnvolle Idee, Whitespace für beides zu 
nutzen: einmal als Anweisung an den Compiler / Interpreter hinsichtlich 
der Blockgrenzen, und andererseits, wie gehabt, um die Les- und 
Wartbarkeit des Code zu verbessern. Eine Win-Win-Situation, sozusagen. 
;-)

Andy D. schrieb:
> Perl (also perl 5) ist zwar dafür berüchtigt dass evtl in 5 Jahre kein
> Mensch mehr den Code lesen kann. Bei vielen Alternativen ist es hingegen
> garantiert dass in 5 Jahren kein Interpreter den Code mehr lesen kann :)

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.

> Eben weil an Perl schon lang genug gearbeitet wurde dass der Drang, alle
> Jahre mutwillig am Sprachkern herumzudoktern, inzwischen vergangen ist.

Das ist ein weiterer Grund, warum Dein Beispiel nicht besonders 
glücklich gewählt ist. Perl6 bricht nämlich die Abwärtskompatibilität -- 
genauso übrigens wie der über viele Jahre vorbereitete und jetzt gerade 
(endlich) vollzogene Übergang von Python2 zu 3 -- und wird damit früher 
oder später genau die Probleme bekommen, von denen Du bislang noch 
glaubst, daß sie nur bei anderen Sprachen vorkommen.

DoS schrieb:
> Egon D. schrieb:
>> DoS schrieb:
>> Mega grottig ist die "GUI-Fähigkeit" die ist auf dem Niveau von 1988.
>> Du redest nicht etwa von "Tk"? Das ist nicht Python-spezifisch.
> Ich meine das TKInter, dass auch am häufigsten in Google hochblobbt wenn
> man Pyton und GUI als Suche eingibt. Das ist wie Grafiken Pixelweise mit
> Texteditoren zu erstellen. Das geht, ist aber nicht Stand der Technik.

Naja, wenn man es wenigstens ein kleines bisschen hübscher haben möchte, 
nimmt man nicht Tkinter, sondern dessen Erweiterung Tix. Die damit 
erstellten GUIs sind aber auch noch nicht so schick und so gut ins 
System integriert wie Qt & Co.

Nebenbei angemerkt kann man mit Tkinter / Tix natürlich auch prima 
objektorientiert entwickeln, auch wenn die allermeisten Tutorials und 
Dokumentationen das leider nicht tun. Man muß nur wissen, daß man die 
super()-Funktion nicht benutzen kann, sondern stattdessen den 
Konstruktor __init__() der Elternklasse manuell aufrufen muß, weil die 
Tkinter- und Tix-Schnittstellen noch auf dem uralten Objektmodell von 
Python basieren, und deswegen leider nicht von object erben.

> Gibt es überhaupt was von Microsoft, das für Linux ist
> (außer ein Migrationstool Linux-> Windows)?

Ja, einiges, zum Beispiel den SQL Server, VScode, Teams und Edge.

Andy D. schrieb:
> Manche Editoren können halbautomatisch anhand der Klammerebenen
> einrücken (zB emacs) - das entlastet den Kopf und bietet auch direkt
> eine Art fortwährenden Syntaxcheck. Und ist mit "klammerarmen" Sprachen
> nicht so gut möglich...

Dann muß mein (GNU) Emacs eine geheimnisvolle Wunderversion sein, denn 
der kann das auch mit Python-Code. ;-)

W.S. schrieb:
> Irgendwer schrieb:
> Stell dir mal eine (hypothetische) Programmiersprache vor, bei der die
> Anzahl der Leerzeichen zwischen Zeilenanfang und Zeilenende
> unterschiedliche Bedeutungen hätte: 3 Stück: Zuweisung, 5 Stück: if, 1
> Stück: while, garnix: goto.

Wir reden hier aber über Python, nicht über irgendwelche hypothetischen 
Strohpuppen, die Du Dir zusammenkonstruierst, um Deine "Argumentation" 
zu stützen.

>> Wo steht, dass Programmiersprachen die Formatierung von Text
>> ignorieren müssen?
> Müssen sie garnicht, aber sie müssen sich gefallen lassen, vom
> Publikum, dem sie zum Gebrauch angeboten werden, eingeschätzt zu werden
> in gute, mittelmäßige, schlechte und kotzmiserable Programmiersprachen.

Tja, und wie das mit dem lieben Publikum so ist: die einen fanden die 
Vorstellung toll, andere mittelmäßig, und einige wenige "kotzmiserabel". 
Sowas soll in einer pluralistischen Demokratie wie unserer sogar 
straffrei möglich sein!

Im Hinblick auf Python befindest Du Dich offensichtlich bei einer 
verschwindenden Minderheit, denn wenn es wirklich "kotzmiserabel" wäre, 
dann wäre es weder die erfolgreichste und verbreitetste 
General-Purpose-Skriptsprache der Welt, noch würde es bei den Umfragen 
von StackOverflow seit vielen Jahre als "Most Wanted" genannt.

Jetzt kann man natürlich gewisse Vermutungen anstellen, wessen 
Einschätzung wohl näher an einer "objektiven Realität" liegt: Deine, 
oder die des Restes der Welt. Mich deucht, daß Du darüber andere 
Ansichten pflegst als ich. ;-)

Nick M. schrieb:
> Walter T. schrieb im Beitrag #6492015:
>> Nee, eigentlich kann man ganz sinnvolle Diskussionen führen.
>
> Nee, man muss nur akzeptieren, dass dieser
> Einrückungsvorschriftsschwachsinn einige extrem nervt (mich z.B.).

Macht ja nichts, es zwingt einen niemand dazu. Aber die solcherart 
Genervten könnten dann in einem Thread, bei dem Gründe für die 
Beliebtheit einer Sprache diskutiert werden, einfach mal etwas tun, das 
ihnen aus völlig unerfindlichen Gründen extrem schwer zu fallen scheint: 
nämlich, einfach mal die Klappe zu halten. Ihr hättet doch einen eigenen 
Thread "warum finde ich Python so doof" aufmachen können, wenn es Euch 
ein unwiderstehliches Bedürfnis ist, anstatt diesen Thread mit Euren 
Vorurteilen zu verunstalten.

Und ja, es sind größtenteils nichts weiter als Vorurteile, die die 
Python-Hasser hier vorzubringen vermögen. 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.

Die Probleme existieren nur im Kopf von Leuten, die keinerlei 
Erfahrungen mit der Sprache haben. Also diesbezüglich vollkommen 
inkompetent sind, nichtsdestotrotz aber ihre engstirnigen Vorurteile für 
so wichtig halten, daß sie sie dem Rest der Welt mit aller Gewalt und 
gern mit verbalen und sozialen Entgleisungen ("Schwachsinn") aufzwingen 
müssen. Was wiederum mich persönlich zu der Vermutung bringt, daß diese 
Leute ganz andere Probleme haben als die Eigenschaften einer Sprache, 
die sie weder kennen noch benutzen, und die sie auch nicht kennenlernen 
oder benutzen wollen.

> Was
> aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen
> Quelltext sind.

Das ist der logische Umkehrschluß, fürchte ich.

> Ich persönlich hab die Einrückerei bei Spin (Propeller)
> hassen gelernt

... und hast wegen Deiner so gewonnenen Vorurteile also auch eine 
Erfahrungen mit Python. Ist ja nicht schlimm, aber: warum äußerst Du 
Dich dann in einem Thread, dessen Thema die Frage "warum ist Python so 
beliebt" ist?

> Eine Sprache steht und fällt mit ihren Bibliotheken. Da ist Python
> sicherlich nicht deutlich schlechter / besser als all die anderen
> Sprachen die Mainstream sind oder waren.

Gerade da ist Python den meisten anderen Sprachen weit voraus.

Nick M. schrieb:
> Sheeva P. schrieb:
>> Jetzt kann man natürlich gewisse Vermutungen anstellen, wessen
>> Einschätzung wohl näher an einer "objektiven Realität" liegt:
>
> Das provoziert doch nur die Antwort mit den Fliegen, notfalls ergänzt um
> Windows.

... die allerdings nur eine ziemlich billige Ablenkung wäre, nicht wahr?

Nick M. schrieb:
> Sheeva P. schrieb:
>> ... und hast wegen Deiner so gewonnenen Vorurteile also auch eine
>> Erfahrungen mit Python. Ist ja nicht schlimm, aber: warum äußerst Du
>> Dich dann in einem Thread, dessen Thema die Frage "warum ist Python so
>> beliebt" ist?
>
> Lies einfach mal meine Beiträge durch. Dann wirst du dir das "Klappe
> halten" nochmal neu überlegen.

Jetzt habe ich Deine Beiträge alle noch einmal gelesen, sehe aber 
bislang keinen Anlaß, meine Position noch einmal zu überdenken. Könntest 
Du mir wohl bitte einen Hinweis darauf zukommen lassen, welches Deiner 
Postings einen Erkenntnisgewinn in Hinsicht auf die Ausgangsfrage des TO 
geleistet hat? Danke.

Nick M. schrieb:
> Walter T. schrieb:
>> Nee, eigentlich kann man ganz sinnvolle Diskussionen führen.
>
> Nee, man muss nur akzeptieren, dass dieser Einrückungsvorschriftsschwachsinn
> einige extrem nervt (mich z.B.).

Aber auch, dass andere sich daran nicht stören und diese doch sehr 
emotionalen Reaktionen nicht nachvollziehen können.

> 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?