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?
:
Verschoben durch Admin
> Was ist an Python so gut?
Python ist ungiftig.
osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? Ja. Vorwort: Bei anderen Programmiersprachen dienen spezielle Wörter oder Zeichen zum Kennzeichnen von Blöcken. Also if (a<3) { blablabla... } bei C if a<3 then begin blablabla... end bei Pascal. Und bei Python gibt es so etwas überhaupt nicht. Dort müssen Blöcke durch Einrückungen gekennzeichnet werden. 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. W.S.
W.S. schrieb: > Und was passiert dort, wenn man 1x Space und dann 1x Tab schreibt? Probiere es doch. Es darf nicht gemischt werden.
osman schrieb: > Vor ein paar Jahren hörte > man überall Perl. Heute hört man davon nichts mehr. Heute hört man nur > noch Python. Also geht es um Interpretierte/Scriptsprachen. Jeder Softwareentwickler muss eine Scriptsprache können. Das hängt auch mit dem Umfeld zusammen in dem du dich bewegst. Ich hatte mal viel mit Perl gemacht, weil das auf jedem Server für CGI unterstützt wurde. Das ist aber schon Jahrzehnte her. Python hab ich schon mal gehört. -) Brauch ich nicht, erscheint mir als Hype. Irgendwer Anders wird sagen, du brauchst PHP (ich nenn das immer Internet-Basic). Frag im Nachbarzimmer, dann ist es Rubi. Frägst du mich, dann ist es Tcl. Nimm die Sprache die dir gefällt oder die, die von dir gefordert wird. Witzig ist, wann die Sprachen entwickelt wurden: Ruby: Mitte 1990 Perl: 1987 Tcl: 1988 PHP: 1995 Python: Anfang 1990 Die liegen innerhalb eines Jahrzehnts und haben sich bis jetzt gehalten.
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.
Python läuft als MicroPython auch auf Microcontrollern!
osman schrieb: > 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? weil es auch zur Kommunikation mit anderen Geräten taugt, so gibt es für den RasPi simple Routinen zur Ansteuerung der IO-Pins: https://www.raspberrypi.org/documentation/usage/gpio/python/README.md Perl ist irgendwie nie über den Gebrauch als Textparser hinausgekommen. Jupyter macht Python noch interessanter, Mit Python umfangreiche Signalanalyse wie FFT samt Visualisierung in einer scriptsprache runterkloppen uhnd gleich mit Interface zum FPGA: https://wiki.trenz-electronic.de/display/PD/TEI0023+-+Demo+ADC+data+acquisition+and+Fourier+transformation Wobei Jupyter mehr ist als nur python
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.
osman schrieb: > Was ist an Python so gut? Es ist eine einfach zu lernende Skriptsprache mit der man schnell zum Ziel kommt. Das macht sie für Einsteiger und Fortgeschrittene beidermaßen interessant.
osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? Nichts. Python scheint insgesamt für viele Anwender einfach gut zu funktionieren. Es gibt jede Menge Projekte, Bibliotheken, Frameworks. Nicht abschließende Aufzählung von typischen Merkmalen, aber wir können ja mal sammeln: W.S. schrieb: > Bei anderen Programmiersprachen dienen spezielle Wörter oder Zeichen zum > Kennzeichnen von Blöcken. > [...] > Und bei Python gibt es so etwas überhaupt nicht. Dort müssen Blöcke > durch Einrückungen gekennzeichnet werden. Das ist Teil eines größeren Plans, Konstrukte möglichst nahe an der natürlichen Sprache zu halten. In C und ähnlichen Sprachen würde es ungefähr heißen:
1 | 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:
1 | 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. Auch wenn es oft eine "richtige" Art gibt, Dinge zu tun, geht es meistens auch anders. Python ist nicht dogmatisch. Beispiele: - Es gibt Typisierung, aber keine deklarierten Typen. Typen werden nur erzwungen, wenn das der Kontext erfordert. Oder wenn der Programmierer das explizit erzwingt. - Es gibt Objektorientierung, aber für eigenen Code (also nicht für Bibliotheken) musst du sie nicht benutzen und kannst auch "einfach" imperativ programmieren. Oder komplett objektorientiert. Oder etwas dazwischen. - Es gibt eine Konvention für private Eigenschaften und Methoden einer Klasse, aber es gibt keinen strikten Mechanismus, der sie durchsetzt. Wenn du eine "private" Eigenschaft von außen ansprechen möchtest, hält dich niemand davon ab. - Es gibt eine Konvention für Konstanten, aber es gibt keine deklarierten Konstanten und wenn du sie unbedingt ändern willst ... Python hat ein paar elegante Datenstrukturen, insbesondere list, tuple und dictionary, die in der Praxis ganz gut funktionieren. Wer stark in Arrays denkt, hat damit am Anfang meistens ein bisschen Probleme, aber irgendwann fällt der Groschen. Nicht unbedingt für den Einsteiger geeignet, aber mit list comprehensions kann man sehr elegant Filterbedingungen ausdrücken. Andere funktionale Konstrukte (curry, lambda) gibt es auch. Python hat eine sehr gute Anbindung zu C (das liegt daran, wie Pyhton intern funktioniert) und damit eine hervorragende Unterstützung für alles, was es auch in C gibt. Auch mit anderen Sprachen und Schnittstellen kommt Python gut klar. Das ist u.a. bei Webanwendungen extrem praktisch, bei der Integration in bereits existierende Projekte und wenn Teilprobleme besser in anderen Sprachen lösbar sind. Python hat einen interaktiven Interpreter, in dem man mal schnell was ausprobieren kann. Vor allem die Introspektion glänzt hier. Paketmanager gibt's auch, aber das hat heute praktisch jeder. Python gibt es seit fast 30 Jahren. Wenn das überhaupt nichts taugen würde, wäre es schon längst in der Versenkung verschwunden. Es ist aber wie mit allen Sprachen: Nichts ist unersetzlich und was wir in 10 oder 20 Jahren einsetzen, weiß heute niemand.
osman schrieb: > Was ist an Python so gut? Das die Industrie neue schnellere Kisten verkaufen kann, damit Programme genauso schnell laufen wie ihre Pendants, die in C/C++/ASM programmiert wurden und auch auf Alt-Systemen so schon eine gute Performance erreichen.
just everything schrieb: > 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. Kann es sein, dass dort bei informatik-aktuell.de Perl und Pearl in einen Topf geworfen wird? https://de.wikipedia.org/wiki/PEARL
Besucher schrieb: > Python läuft als MicroPython auch auf Microcontrollern! Warum sollte man sich das antun? Oder warum sollte man das überhaupt machen? Weil man kein C kann?
was ist das besondere an der programmiersprache Python? ----- Das frage ich mich auch. Eine "Programmiersprache", die per wrapper-Funktionen mit richtigen Programmiersprachen kommuniziert und ihre Libs nutzt. Pfui Deibel.
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.
:
Bearbeitet durch User
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?
just everything schrieb: > Ja, aber auf sehr unterschiedlichen Rankings: Das ist so wie mit Microsoft-Produkten. :-)) Man sollte sichj aber auch noch den zeitlichen Verlauf ansehen. Da erkennt man schon, dass das in den letzten Jahren zugelegt hat. Ist aber eher egal, läuft nur auf einen language war raus. Ich lerne jetzt mal OCaml ...
Gegenfrage: Was bringt einem Delphi? Was bringt einem COBOL? Was bringt einem die Programmiersprache JAVA? Nun, bei letzterer haben wir eine extrem unsichere Basis, tausendfach geflickt, mittlerweile vielleicht nicht mehr ganz so extrem. Trotzdem extrem flexibel, kann ohne weitere Toolkits grafische Oberflächen darstellen und ist portabel. Es wird millionenfach an Schulen und Universitäten gelehrt. Darum ist es auch weit verbreitet. Wenn man es versteht, kann man unendlich viele Programme von anderen Lesen, verändern oder eigene Programme mit dem eigenen dort erworbenem Wissen erstellen. Bei Python verhält es sich ähnlich. Allerdings wird Python weniger für GUI Anwendungen benutzt, sondern für Programme auf der Konsole oder beispielsweise für die Programmierung von Plugins. Wer beispielsweise mit KiCAD Platinen erstellt, kann dafür Plugins benutzen, die in Python geschrieben sind oder selber welche erstellen. Ich persönlich mag Python auch nicht besonders, aber Perl finde ich schlimmer... So hat jedes Werkzeug eigene, spezielle Eigenschaften, die es für einen besonderen Zweck geeignet machen.
Hmmm schrieb: > Warum sollte man sich das antun? Oder warum sollte man das überhaupt > machen? Weil man kein C kann? Genau. So geschehen bei einem Vollpfosten bei mir in der Arbeit. Aber wenn man so schlau ist einen Router zu cracken damit man seine eigene SW installieren kann und dann die Zeitbombe an Kunden verkauft, wohl wissend, dass man kein Update mehr installieren kann ...
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!
:
Bearbeitet durch User
Hmmm schrieb: > Besucher schrieb: >> Python läuft als MicroPython auch auf Microcontrollern! > > Warum sollte man sich das antun? Oder warum sollte man das überhaupt > machen? Weil man kein C kann? Weil der Stundenlohn des Pythonprogrammierer günstiger ist als der des C Programmierer und weil der Pythonprogrammierer aufgrund der Sprache schneller zum Ziel kommt. Beides spart Geld. Der Preis dafür ist eine höhere Leistungsanforderung an die Hardware. Jetzt kommt's also darauf an, wie hoch die Stückkosten sind. Produzierst du ein paar Millionen Stück davon, dann könnte es wichtiger sein am µC 3 Cent pro Stück zu sparen und die Software dann lieber in C zu entwickeln.
Gruss zur Nacht, am Morgen Ich hatte mich mal für eine Skriptsprache interessiert, probierte dann das anfängliche Python aus, viele Versprechungen, oh graus, da lief aber nichts. Ich nahm dann newLisp mit GUI und java(Server), das ging gut, möchte ich nicht missen. Aber nicht "direkt" mit einem Mikrocontroller. Dirk St
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. :)
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.
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.
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. Diese Tabs/Leerzeichen von Python finde ich z.B. grausam lesbar und irre schlecht wartbar. Jeder Profi den ich kenne lehnt Python als vollwertige Sprache ab, alleine aufgrund der Einrückungen. Natürlich kann man damit kurze Scripte schreiben, dafür reicht es. Aber ich würde niemals damit einen µC oder ein größeres Projekt umsetzen.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Ben S. schrieb: > Eine Klammer kann ich hingegen nicht vergessen. Ne' Einrückung schon. gequirlte Scheisse. Ein Programmierer, der nicht weiss, auf welcher Ebene in seinem Programm er sich bewegt, hat keine Ahnung. Und die Ebene gibt die Einrückung vor. Eine Klammer kann ich vergessen und dann fängt die Suche an, wo die vergessen wurde.
//.|.\\ 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 🙄.
:
Bearbeitet durch User
Aktiv Unsinn machen ist eigentlich in keiner Programmiersprache besonders schwer.
Beides Fehler, die einem eine ordentliche Entwicklungsumgebung zeigen sollte. Messdaten können mit Python super einfach aufbearbeitet werden, zusammen mit Jupyter kann man direkt eine präsentable Seite vorweisen.
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.
:
Bearbeitet durch User
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: > gequirlte scheisse. Die fehlende Klammer erzeugt eine Fehlermeldung. Und woher weiss der Compiler, wo die Klammer hinsoll ???
Sheeva P. schrieb: > 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 Natürlich! Ich habe ja auch nicht behauptet, dass es das nicht gäbe, der Anteil der allein in Python geschriebenen Programme mit GUI ist im Verhältnis zu in anderen Programmiersprachen geschriebenen Programmen aber relativ gering. Wer C beherrscht, kann in C grafische Oberflächen auch nicht ohne Toolkit, wie z.B. GTK erstellen. Wie bereits geschrieben, für jeden Zweck gibt es ein passendes Werkzeug, manchmal ist es halt etwas umständlich zu bedienen. Man nutzt das, was man beherrscht, und das ist in vielen Fällen eben Java (fast jede Android-Anwendung ist in Java geschrieben). Wer z.B. Plugins für eine Vielzahl von Programmen schreiben will, ist mit Python meist gut bedient. Soll jetzt aber kein Flamewar werden, sondern eine reine Feststellung.
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.
:
Bearbeitet durch User
Ja, woher nimmt man dann Matlab? Wer ist bereit soviel Geld privat zu bezahlen? Da ist Python in der Tat eine sehr gute Alternative.
OK, jetzt hat also jeder verstanden, dass Python Einrückungen fehleranfällig sind. Und dass die Paarung der Klammerung in C/C++... der Fehler eines einzelnen fehlenden Zeichens erkannt wird (leider meist durch seltsame Fehlermeldungen.). Wie sieht es denn mit anderen Besonderheiten aus? Hat Python mehr/weniger Fälle von undefined behavoir / unspecified behavior als C / C++?
Klaus schrieb: > Wie sieht es denn mit anderen Besonderheiten aus? > Hat Python mehr/weniger Fälle von undefined behavoir / unspecified > behavior als C / C++? Nein, weil ein Interpreter würfelt genauso wenig wie ein Compiler. Was da als 'undefined behavoir' gebrandmarkt wird ist in Wirklichkit nur die Faulheit des Anwender das Manual oder ggf den Source zu lesen.
//.|.\\ 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.
Beitrag #6489592 wurde von einem Moderator gelöscht.
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?
:
Bearbeitet durch User
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 ...
:
Bearbeitet durch User
Nick M. schrieb: > Hmmm schrieb: >> Warum sollte man sich das antun? Oder warum sollte man das überhaupt >> machen? Weil man kein C kann? > > Genau. So geschehen bei einem Vollpfosten bei mir in der Arbeit. > Aber wenn man so schlau ist einen Router zu cracken damit man seine > eigene SW installieren kann und dann die Zeitbombe an Kunden verkauft, > wohl wissend, dass man kein Update mehr installieren kann ... Was das mit Python zu tun haben soll bleibt im dunkeln.
Wodjanoi schrieb: > Nein, weil ein Interpreter würfelt genauso wenig wie ein Compiler. Was > da als 'undefined behavoir' gebrandmarkt wird ist in Wirklichkit nur die > Faulheit des Anwender das Manual oder ggf den Source zu lesen. Wirklich? Es gibt den Begriff undefined behavior in C/C++. ISO/IEC 14882:2003(E): Programming Languages - C++ §1.3.12 undefined behavior Das sollte eine ernste Frage sein. (Ich arbeite mit C/C++ und Python, jede Sprache hat Vor- und Nachteile). Für C/C++ wurde eine Zusammenfassung von undefined behavior gemacht. Gibt es das auch für Python? Über die Suche habe ich zwar einzelne undefined behavior Punkte gefunden, aber keine Zusammenfassung.
Walter T. schrieb: > effiziente Programmiersprachen wie Matlab Hast du mal einen Performanceǘerglich von Matlab und NumPy gemach? Ich glaube nicht, dass da Matlab signifikant besser ist.
Roland F. schrieb: > 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. Mit welcher Begründung (die über ein will ich nicht oder kann ich nicht hinaus geht)? Oder pflegst du einen Programmierstil bei dem man in Python erst weit nach rechts scrollen muss, bis der erste Code erscheint?
Klaus schrieb: > Wodjanoi schrieb: >> Nein, weil ein Interpreter würfelt genauso wenig wie ein Compiler. Was >> da als 'undefined behavoir' gebrandmarkt wird ist in Wirklichkit nur die >> Faulheit des Anwender das Manual oder ggf den Source zu lesen. > > Wirklich? Es gibt den Begriff undefined behavior in C/C++. > ISO/IEC 14882:2003(E): Programming Languages - C++ §1.3.12 undefined > behavior > > Das sollte eine ernste Frage sein. 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. >Ich fand schon immer die Entscheidung, das die Quelltextformatierung >Teil der Syntax b.z.w. Semantik ist schlecht. Und ich finde es es gut, wenn 'die Coder' zur Abfertigungn eines wenigsten minimal strukturierten Quelltextes mit daraus resultierender verbesserter Lesbarkeit für Menschen gezwungen sind. C erlaubt zuviel "Katzenpolka auf der Tastatur", bspw:
1 | for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); |
Wodjanoi schrieb: > C erlaubt zuviel "Katzenpolka auf der Tastatur", bspw: > for(;P("\n"),R--;P("|"))for(e=C;e--;P("_"+(*u++/8)%2))P("| "+(*u/4)%2); Vielleicht einfach mal clang-format installieren? Wenn jemand so seinen Quelltexte formatiert, dann ist es sein Problem (oder ausdrücklicher Wunsch). Bei mir wird der gleiche Quelltext dann automatisch so formatiert, wie ich es gern habe.
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
was ist ein eindeutiger Compileroutput? Kann das auch eine Fehlermeldung sein? Irgendwie finde ich diese nicht immer eindeutig.
gar kein problem schrieb: > Wenn jemand so seinen Quelltexte formatiert, dann ist es sein Problem > (oder ausdrücklicher Wunsch). Nein die dritten, die diesen alienhaften Fremdcode debuggen/erweitern müssen haben ein Problem damit, das der Coder solch ein Radebrech als 'wünschenswert' ansieht. >Bei mir wird der gleiche Quelltext dann > automatisch so formatiert, wie ich es gern habe. Du sollst aber keinen Code zum individuellen 'Gern haben' verfassen oder verformatieren, sondern gut les- und wartbaren. Das ist für Community-gepflegten 'Open Source' unerläßlich. Daher ist es ein interessanter Ansatz das manche Sprachdefinitionen extra Konstrukte enthalten um die masochistische oder sadistische Neigung mancher Coder bewußt zu lenken/begrenzen. Formatierung/Codestil ist kein Selbstzweck.
Wodjanoi schrieb: > Und das ist eine ernsthafte Anwort - ein Compiler würfelt nicht. Der > Source definiert immer einen eindeutigen Compileroutput. Das wird jetzt spitzfindig. Fakt: undefined behaviour wird in den Standards genutzt. Kennst Du alle? Hast Du das Kapitel gelesen? Inklusive der implementation defined behaviors? > Ein Compiler würfelt nicht OK, so kann man es sagen. Aber das Ergebnis kann gewürfelt sein. So mir passiert, weil das Verhalten eines Codeteiles plötzlich abhängig wurde von zufälligen Werten in Registern. Ich will nicht C angreifen, ich nutze es ja, auch gerne und kenne die Schwachstellen. Meine Frage war, ob jemand eine Übersicht der Schwachstellen (undefined behaviour) in Python kennt.
gar kein problem schrieb: > as ist ein eindeutiger Compileroutput? Das binary/executable das der Compiler/linker erzeugt. > Kann das auch eine Fehlermeldung > sein? Irgendwie finde ich diese nicht immer eindeutig. Du verwechselst Verständlichkeit mit eindeutigkeit. Für den Compiler ist es schon eindeutig klar, das er diesen Input nur mit dieser Error-meldung zu quittieren hat, auch wenn es für Dich nicht verständlich sein sollte, das Mama's Liebling da einen Fehler gebaut hat. ;-)
Wodjanoi schrieb: > sondern gut les- und wartbaren. Das ist für > Community-gepflegten 'Open Source' unerläßlich. Dann soll diese Community ihre Files mit clang-format und Co. einheitlich formatiern. Und erst dann zum Download anbieten. Das ist doch besser und sicherer wenn ein Programm das automatisch macht und nicht die Programmierer selbst.
Klaus schrieb: > Fakt: undefined behaviour wird in den Standards genutzt. > Kennst Du alle? Hast Du das Kapitel gelesen? > Inklusive der implementation defined behaviors? Ja ich hab genug gelesen um zu wissen was damit gemeint ist, der Einfluß von verschiedenen Sprachkonformen Compilerimplementierungen und ausführender Hardware >> Ein Compiler würfelt nicht >Aber das Ergebnis kann gewürfelt sein. >So mir passiert, weil das Verhalten eines Codeteiles plötzlich abhängig >wurde von zufälligen Werten in Registern. Das ist keine spontane Abhängigkeit, das ist ein unsauberer/unportierbarer/hardwareabhängiger Programm. Und dafür zeichnet der Programmierer verantwortlich, das er keine definierten Startbedingungen (initialisierung der Registervariable) garantiert hat. >Meine Frage war, ob jemand eine Übersicht der Schwachstellen (undefined >behaviour) in Python kennt. Die Schwäche liegt eher beim Coder der nicht begriffen hat, wie eine CPU funktioniert und das man nur dann definierte Ergebnisse erwarten kann, wenn alle Anfangsgrößen definiert aka initialisiert sind.
Karl schrieb: > Hast du mal einen Performanceǘerglich von Matlab und NumPy gemach? Ich > glaube nicht, dass da Matlab signifikant besser ist. Ich jetzt nicht. In der Uni hat mal jemand nen Vortrag halten sollen über den Performancegewinn von Vectorisierten Berechnungen gegenüber per For-Schleife. Das Ende vom Lied war, die neue Matlab Version hat die For-Schleife selber erkannt und war fast genauso schnell. Ich vermute mal, dass sich Vektorrechnungen in Numpy performancemäßig kaum von Matlab unterscheiden. Aber wenn du ne Python-For über Numpy Arrays machst, ist das sicherlich deutlich langsamer als alles, was du in Matlab machst. ... Hmm pypy unterstützt inzwischen Numpy oder? Das könnte auch schnell sein. Aber Numpy ist ja wahrscheinlich dennoch ne externe Bibliothek und so... Also mit pypy will ich mal keine Aussage treffen.
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.
Ich hab mit Python noch nicht viel und mit numpy noch gar nichts gemacht, nur der Hinweis: Von <3Min auf "ich habs irgendwann abgebrochen" bin ich auch mit Matlab alleine schon gekommen. Klassiker: Statt Matrizenrechnung in zwei verschachtelten for-Schleife durch die Matrizen iterieren. Das Tool heißt nicht umsonst MATrix LABoratory. Vermutlich gibt es bei numpy ähnliche Fallstricke. Das nur, um einen einzelnen Datenpunkt einzuordnen. MfG, ARno
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.
Python ist so eine Art QuickBASIC der "Neuzeit". Leicht zu verstehen, leicht anzuwenden. Es hat sich wohl vor allem an Unis eingebürgert. Auch informatikferne Studenten können schnell den Umgang damit lernen. Oft ist es wohl so, dass die eigentlichen Funktionen oder Routinen in C++ oder anderen "schwierigen", aber schnellen Sprachen programmiert sind und der User von Python aus darauf zugreift.
Wodjanoi schrieb: > Das ist keine spontane Abhängigkeit, das ist ein > unsauberer/unportierbarer/hardwareabhängiger Programm. Und dafür > zeichnet der Programmierer verantwortlich, das er keine definierten > Startbedingungen (initialisierung der Registervariable) garantiert hat. Ich habe gültigen Code geschrieben. Der Sprachstandard und der Compiler haben daraus undefiniertes Verhalten gemacht. Ohne dieses Verhalten wäre alles OK gewesen. Es hätte keine nicht initialisierte Variable gegeben. Aber du hast Recht: ich war zu blöd zu sehen, dass hier ein UB vorliegt. Schon Lustig, man driftet immer vom Thema ab. Eigentlich ging es mir ja um UB bei Python.
Dann nochmal komplett, weil einige den Context verloren haben: Hmmm schrieb: > Besucher schrieb: >> Python läuft als MicroPython auch auf Microcontrollern! > > Warum sollte man sich das antun? Oder warum sollte man das überhaupt > machen? Weil man kein C kann? Meine Antwort darauf, ergänzt um das Stichwort MicroPython. > Genau. So geschehen bei einem Vollpfosten bei mir in der Arbeit. > Aber wenn man so schlau ist einen Router zu cracken damit man MicroPython und > seine > eigene SW installieren kann und dann die Zeitbombe an Kunden verkauft, > wohl wissend, dass man kein Update mehr installieren kann ...
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.
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.
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++ ;-)
:
Bearbeitet durch User
Beitrag #6489983 wurde von einem Moderator gelöscht.
Arno Dübel schrieb im Beitrag #6489983:
> ich sauf mir jetzt ein
Wenn man nix anderes kann ...
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!
Le X. schrieb: > Von dem Thema Whitespaces abgesehen gefällt mir > Python ganz gut. Man kriegt in wenigen Zeilen > enorm viel Funktionalität reingequetscht, [...] Das gilt aber für andere Scriptsprachen auch (z.B. Tcl); das erklärt also nicht, warum ausgerechent Python so beliebt ist... > Bei größeren Projekten stört mich die fehlende > Typisierung sowie dass jeder auf so gut wie alles > zugreifen kann. Das geht mir witzigerweise bei Tcl genauso...
Ich finde Python ganz ok, dafür dass es nichts kostet und doch ganz schön mächtig ist. Manche Konstrukte sind schon ganz schön unlogisch und die fehlende Typisierung gefällt mir nicht. Mega grottig ist die "GUI-Fähigkeit" die ist auf dem Niveau von 1988. 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.
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. > Wenn ich das mit VisualBasic aus den 1990ern vergleiche, > war das damals besser gelöst. Komisch. Von VisualBasic für Linux habe ich nie etwas gehört...
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.
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..
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?
Sheeva P. schrieb: > Einerseits sehe ich das (noch?) lange nicht, daß Rust eine größere Rolle > spielt, im Moment scheint das Momentum eher bei Go zu liegen. Naja, kommt darauf an, in welchem Gebiet man sich bewegt. Go kann C und C*+ nicht ersetzen, da es keine Sprache ist, die für die Systemprogrammierung geeignet ist. Rust schon. Rust ist vom Einsatzfeld viel näher an C und C++ als es Go je war, kann aber trotzdem auch in Gebiete vorrücken, für die man C oder C++ nur ungern verwenden würde. > Andererseits spielt Rust in einer Diskussion, in der es um die > (meistens) interpretierte General-Purpose-Skriptsprache Python geht, > wohl auch keine Rolle. Ja, das ist natürlich wahr. Ich wollte es nur mal erwähnen, weil du von (r)evolution sprachst.
Le X. schrieb: > Aber scheinbar hat Python etwas was die Leute wollen, Tcl nicht. > Und nu? Vivado, Quartus ohne Tcl? Und nu? Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC oder Arm.
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 weil die Raspberry-Entwickler/Foundation diese Sprache favorisieren und es einfach massiv viele Tutorials und Hilfen dazu für den Raspberry gibt. Will man irgendwas mit Raspberry automatisieren, findet man höchstwahrscheinlich Hilfestellungen mit Python dazu, obwohl das Problem auch mit einer anderen Sprache lösbar wäre. Und durch diese so entstandene Popularität von Python, wird diese Sprache auch immer mehr auf Windows-Systemen eingesetzt.
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.
Sheeva P. schrieb: > 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. Das könnte man vielleicht auch bei C/C++ optional einführen. Funktionsblöcke ohne Einrückungen können da ja schon mal zu schweren Übersichtsproblemen führen. Am besten eine Option "automatisierte Einrückung" auf Mausklick im markierten Bereich :)
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.
Heiner schrieb: > Das ist Teil eines größeren Plans, Konstrukte möglichst nahe an der > natürlichen Sprache zu halten. 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. 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; ... Bei Pascal wäre das weitaus lesbarer: var i : integer; ... for i:= 0 to 4711 do irgendwas; oder for i:= 4711 downto 0 do irgendwas; Du wirst wohl nicht bestreiten, daß das ausgesprochen klar lesbar ist. > Python macht daraus ein einfaches: > for abc in xyz: Das wiederum ist extrem unverständlich und auch genau so nicht erwünscht. 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. Und ohne eine dedizierte Laufvariable geht das nicht. 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. > ... 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. Dazu würden nämlich die konkret instantiierten Members erforderlich sein, denn die wären es ja, die da aufgezählt werden sollen. Die Klasse an sich weiß das nicht, sie ist ja nur der Datentyp, aber nicht die Instantiierung durch konkrete Variablen. W.S.
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...
:
Bearbeitet durch User
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. OK, wir nehmen Fortran hier mal heraus, das hat Alters-Bestandsschutz. Aber für alle anderen sogenannten 'probllemorientierten' Programmiersprachen (im Klartext: alles außer Assembler) gilt, daß man für Blöcke eben Kennzeichner hat. Python hat diese nicht und Einrückungen sind keine derartigen Kennzeichner, sondern nur ein Mittel zur grafisch angenehmen Darstellung. Darum. W.S.
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.
//.|.\\ schrieb: > Und woher weiss der Compiler, wo die Klammer hinsoll ??? Junge, eben weil am Ende eine öffnende oder schließende zuviel ist. Spätestens dann merkt er es. Da können dann zwar einige Zeilen dazwischen liegen, aber man wir wenigstens drauf aufmerksam gemacht. Das ist der Punkt. W.S.
Das angebliche Python-Whitespace/Tab-Problem ist eine Schein-Diskussion,
das Problem existiert nicht:
a.) Weiter oben wurde schon geschrieben, Python (3) bringt eine
Fehlermeldung bei mixed Whitespace/Tabs.
b.) Jeder f*cking Editor kann eingestellt werden, wie die Tab-Taste
funktionieren soll, ob Whitespace oder Tab, etc.
c.) editorconfig ist erfunden. Jedes Projekt kann seine eigenes Setting
verwenden, und man merkt nicht mal was davon, egal welchen Editor
man verwendet.
Wozu sich über etwas Gedanken machen, das längst komplett gelöst ist?
Macht sich hier einer Gedanken, auf welchen Sektor einer Festplatte eine
Datei gespeichert wird?
Wer natürlich heute noch (ungewartete) Editoren aus dem letzten
Jahrtausend benutzt, nun denn, werdet glücklich damit und plagt euch mit
Nebensächlichkeiten rum.
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. 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?! Also, echt jetzt...
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... ;-)
Irgendwer schrieb: > Das angebliche Python-Whitespace/Tab-Problem ist > eine Schein-Diskussion, Keineswegs. > das Problem existiert nicht: Doch. Dass die Blockstruktur in Python durch Einrückung definiert wird, bedeutet im Umkehrschluss, dass es kein druckbares Zeichen (wie z.B. "begin", "end", "{","}",...) gibt, das die Blockstruktur definiert. 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.
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.
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. Nein -- das ist logisch: Eine Sprache, die solchen Blödsinn als unverrückbares Element enthält, die fasse ich nicht an, egal, wie gut sie ansonsten ist. Überdies habe ich ja auch keinen Bedarf; ich bin mit Tcl zufrieden. Ich würde auch kein Kabel kaufen, das eine rote Ader für den Schutzleiter enthält, "nur um den Elektriker zu erhöhter Aufmerksamkeit zu zwingen".
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?
Egon D. schrieb: > Nur Python kennt nix. Tja. Wenn Du wüsstest, das es noch eine ganze Reihe aktueller, aktueller Programmiersprachen gibt, bei denen Struktur durch Einrückung erzeugt wird... 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.
Beitrag #6490545 wurde von einem Moderator gelöscht.
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. ;-)
W.S. schrieb: > Python hat diese nicht und Einrückungen sind keine derartigen > Kennzeichner, sondern nur ein Mittel zur grafisch angenehmen > Darstellung. Quelltext wird einmal geschrieben, und ein vielfaches oft gelesen. Einem Compiler ist es egal, nach welchen Regeln hierarchische Strukturen kodiert werden. Ob Klammern, Schlüsselwörter oder Einrücktiefe. Piep egal, für einen Compiler. 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. In allen (strukturierten) Programmiersprachen dieser Welt, rücken Programmierer ihren Quelltext hierarchisch ein, weil es sonst keine Sau mehr lesen kann. Es ist nur logisch, die Einrückung zur Strukturierung zu verwenden. Dann ist es nicht möglich, eine Diskrepanz aus Einrückung und tatsächlicher Struktur des Quelltexts zu erzeugen. Eine Fehlerquelle weniger, mehr Klarheit und Konsistenz, bessere Lesbarkeit. Und genau das ist ein entscheidende Faktor für Software-Qualität: Klar verständlicher Quelltext. Quelltext wird für Menschen geschrieben, die den Kram lesen und verstehen müssen.
Beitrag #6490554 wurde von einem Moderator gelöscht.
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. Stopp. 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. > Unsere ganze Schriftkultur besteht aus Blöcken und > Einrückungen. ... und aus Interpunktion. > In allen (strukturierten) Programmiersprachen dieser > Welt, rücken Programmierer ihren Quelltext hierarchisch > ein, weil es sonst keine Sau mehr lesen kann. Korrekt. > Es ist nur logisch, die Einrückung zur Strukturierung > zu verwenden. 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). Der Mensch braucht die Einrückung, das ist korrekt -- ich will aber dem Computer nicht durch die Anzahl der Leerzeichen mitteilen müssen, welche Blockstruktur ich haben will! Setzer können schon seit Jahrhunderten verschieden breite Leerräume erzeugen -- trotzdem setzen wir noch einen Punkt, wenn der Satz zu Ende ist. 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".
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).
Beitrag #6490576 wurde von einem Moderator gelöscht.
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...
Max M. schrieb: > 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: > if 1 < 2: > print('yes') Ach. Na jetzt bin ich ja baff. Habe ich das jetzt richtig verstanden: Außer Dir hält es NIEMAND -- nicht einmal die deutschsprachige Wikipädie -- für wichtig, auf den verbreiteten Irrtum hinzuweisen, 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? > 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 Programmier- > sprachen automatische Code-Formatierer wie prettier, > clang-format etc. Ja, ist im Prinzip klar. Es ging mir um einen anderen Punkt: Mein Vorschreiber "Irgendwer" hat zu Recht daraufhingewiesen, dass 1. der Mensch für seine Wahrnehmung Einrückungen braucht und 2. Redundanz gefährlich sein kann, weil redundante Angaben widersprüchlich sein können. 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. Mein Gegenargument ist: Die Mensch-Maschine-Kommunikation hat zwei Richtungen, nämlich Mensch-->Maschine und Maschine-->Mensch. Für die Richtung "Mensch-->Maschine" möchte ich DRUCKBARE Zeichen, die die Blockstruktur DEFINIEREN. Um Widersprüche durch schädliche Redundanz zu vermeiden, folgt daraus, dass die für die Richtung "Maschine-->Mensch" notwendigen Einrückungen AUTOMATISCH aus den druckbaren Zeichen generiert werden müssen. Diese SIGNALISIEREN die Blockstruktur NUR FÜR DEN MENSCHEN, sind aber für die Maschine nicht verbindlich, sondern im Gegenteil abgeleitete (=redundante) Informationen. > 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). Theoretisch sicherlich richtig. Praktisch ist die Bedeutung dessen fraglich, wenn chiffrierte Fünfergruppen gesendet werden :)
Beitrag #6490590 wurde von einem Moderator gelöscht.
Diese ganze Whitespace-Diskussion liest sich irgendwie, als würde der Stumme dem Blinden Farben erklären. Kann gutgehen, ist aber meist ne Sauerei. Kann nicht mal einer ein Beispiel geben, damit alle wissen worüber Diskutiert wird? Die Behauptung ist doch, dass Pseudocode A:
1 | res = 0 |
2 | for i in 1..2: |
3 | res = res+1 |
4 | res = res+1 |
Pseudocode B:
1 | res = 0 |
2 | for i in 1..2: |
3 | res = res+1 |
4 | 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. Meine Meinung: a) Whitespace ist nicht optimal, es macht Code kopieren und neu strukturieren zur Strafarbeit. b) Äpfel mit Birnen verglichen, der äquivalente Fehler in "klammerbasierten" Sprachen ist nicht "Klammer vergessen" sondern "Statement außerhalb des Blocks" Wobei man bei a) noch einwerfen kann, das das Absicht ist: Code einfach aus dem Netz kopieren und hoffen ist idiotisch. Die Realität: Ich schreibe code in sh und bash. Mit perl bin ich nie warm geworden, komme mit gut strukturiertem Fremdcode aber klar. Bei Python bin ich über einige Schnipsel und das flicken von Fremdquellen nie hinaus gekommen - nicht das ich nicht wollte, aber entweder es gab kein Python (Router, embedded), ich hatte keine Zeit das zu lernen oder der Editor bereitete Schmerzen. Versuche, python zu lernen mach ich immer wieder.
M.K. B. schrieb: > 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. Das kannst du auch in Python bekommen. Type hints sind Bestandteil der Sprache, und mit mypy gibt es ein statisches Analysetool das diese auf Konsistenz prüft. Ich habe damit in größeren Projekten sehr gute Erfahrungen gemacht. Die Whitespacediskussion halte ich für völlig überzogen. Ich habe bis vor ein paar Jahren auch nur mit anderen Sprachen gearbeitet die so etwas nicht hatten, aber da gewöhnt man sich schnell dran, lernt es sogar zu schätzen (und man spart sich im Code Review die Diskussion darüber ob etwas richtig eingerückt ist).
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.
Axel S. schrieb: > 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. In größeren Projekten bin ich für jeden „Zwang“ dankbar den eine Sprache bietet. Jedes im Wesentlichen belanglose Detail (wie Einrückung oder Groß-/Kleinschreibung von Klassen/Methodennamen) das von der Sprache festgelegt wird ist ein Detail weniger für das man Richtlinien schreiben, über das man in Code Reviews diskutieren oder neue Teammitglieder einweisen muss. Python, autopep8, mypy, google docstring guidelines, und man kann sich wirklich auf das wesentliche konzentrieren. Mit 50 Leuten an einem Projekt in Perl zu arbeiten, stelle ich mir z.B. die Hölle vor. Wahrscheinlich ist das sogar noch schlimmer wenn alle 50 davon Perl-Experten sind ;)
Rolf M. schrieb: > 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. Nein, so war das nicht gemeint. Ich habe compilierbaren Code (so meinte ich das "gültige") geschrieben, der aber undefined behavior hatte. Ist ja erlaubt. Der Standard verbietet mir ja nicht so etwas zu tun. War meine Blödheit/Vergesslichkeit nicht an das Verhalten zu denken. 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. > 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... :-)
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... :-) :)
W.S. schrieb: > Und bei Python gibt es so etwas überhaupt nicht. Dort müssen Blöcke > durch Einrückungen gekennzeichnet werden. > > 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! Genau. Weil auch nur irgendeine Programmiersprache wegen ihrer Syntax verbreitet ist.
vn nn schrieb: > Genau. Weil auch nur irgendeine Programmiersprache wegen ihrer Syntax > verbreitet ist. Brainfuck? Als Sprache, nicht als Zustand!
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.
:
Bearbeitet durch User
Ich hätte eine Sprache, auf der man vereint und ersatzweise drauf rumhacken kann: PL/SQL Ich hätte damit Web-Anwendungen programmieren sollen. Da hab ich lieber gewechselt. WebObjects wollte der Chef nicht, das war ihm wohl zu genial.
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. 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. 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. Die Zwischenräume gibt es üblicherweise nur dazu, zwischen den Zeichen/Wörtern zu trennen. 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. Das ist genauso, als wenn man als Konvention herausgeben wollte, daß Marken in Spalte 1 und Ergibtanweisungen in Spalte 5 und if, then, else in Spalte 3 zu beginnen hätten. 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. W.S.
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
:
Bearbeitet durch User
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.
W.S. schrieb: > 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. Offensichtlich nicht, da Python ansonsten nicht exisitieren könnte. Abgesehen gibt es eine UN Konvention oder Sonstiges, dass Whitespace nicht semantisch sein darf. W.S. schrieb: > 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. Ganz sicher nicht - Es ist ein Haufen Logik notwendig um die richtige Einrückung trotz Space/Tab Verwechslungen herauszufinden. Ich stelle mir vor, dass irgendein Dozent angepisst war weil seine Studenten sich nicht um lesbare Einrückung gekümmert haben und dann Python erfunden hat um sie zu dahinzubringen. 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.
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.
:
Bearbeitet durch User
Le X. schrieb: > Und wenn ich Python grundsätzlich ganz gern mag, mit Klammern oder > Keywords anstelle Whitespaces zur Blockkennzeichnung aber noch besser > finden würde? Dann mach doch ein Karl Klammer Mod ;) Man könnte aber auch sich darum bemühe eine Mehrheit zu finden und die Entwickler von Python von diesem Konzept mit Klammern zu überzeugen, wenn es einem wirklich so wichtig ist.
Le X. schrieb: > Und wenn ich Python grundsätzlich ganz gern mag, mit Klammern oder > Keywords anstelle Whitespaces zur Blockkennzeichnung aber noch besser > finden würde? Dann nimmt man Python with Braces: https://python-with-braces.appspot.com/
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. > Wenn ich das mit VisualBasic aus den 1990ern vergleiche, war das damals > besser gelöst. > > Komisch. Von VisualBasic für Linux habe ich nie etwas gehört... 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)?
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 ...
:
Bearbeitet durch User
W.S. schrieb: > Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen > aus druckbaren Zeichen bestehen Warum? Wo steht, dass Programmiersprachen die Formatierung von Text ignorieren müssen? Offensichtlich funktioniert es doch wunderbar. Python und andere Sprachen die das genau so machen, existieren und sind real. Also, warum müssen ausschließlich "druckbare" Zeichen verwendet werden? [Ein Leerzeichen ist "druckbar". Es kommt nur keine Tinte aufs Papier. So wie bei einem "O" die Fläche auch nicht gedruckt wird, sondern nur ein Kreis]
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.
:
Bearbeitet durch User
DoS schrieb: > hochblobbt ... Grafiken Pixelweise Du hast von Tk soviel Ahnung, wie von der Rechtschreibung ;) leo
W.S. schrieb: > 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. Nachdem ich schon einige Interpreter und Parser geschrieben hab: Nein, absolut nein. Kein normaler interpreter zählt whitespaces. Die whitespaces beenden ein token und werden dann konsumiert bis zum nächsten Zeichen. lc und cc (linecount und charactercount) braucht man höchstens für Fehlermeldungen, sonst sind die nur lästiges Beiwerk.
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...
Andy D. schrieb: > Manche Editoren können halbautomatisch anhand der Klammerebenen > einrücken (zB emacs) Noch wilder! Die machen sogar eine geschlossene Klammer wenn man die zugehörige offene geschrieben hat. Natürlich sprachabhängig. Ich editiere soeben eine Datei mit der Endung .ml und Sublime weiss, was das sein soll. Und ich tippe '(' und dann steht da '()' und der Cursor steht auf dem ')'. Und mit der Endung .c nach einem '{<return>' rückt der auch richtig ein!!!!eins11elf Echt irre, was Editoren so können um Fehler zu reduzieren.
Irgendwer schrieb: > W.S. schrieb: >> Aber: Programmiersprachen bestehen aus Sprachelementen und diese müssen >> aus druckbaren Zeichen bestehen > > Warum? Weil man ja sonst nichts würde lesen können. 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. > 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. W.S.
W.S. schrieb: > Stell dir mal eine (hypothetische) Programmiersprache vor, bei der die > Anzahl der Leerzeichen Nicht so hypothetisch: https://en.wikipedia.org/wiki/Whitespace_(programming_language) leo
Rolf M. schrieb: > Du hast es aber als Katastrophe dargestellt, dass es nur mit > vernünftiger Einrückung geht. Daraus habe ich geschlussfolgert, Das war eine geradezu böswillige Unterstellung. Also nochmal zum Mitbuchstabieren: 1. Einrückungen sind zum gefälligen optischen Bild, wenn man sich die Quelle anschaut. 2. Blockbegrenzer (begin, end, {, }, oder sonstwas druckbares) sind für das klare Abgrenzen von Blöcken - sowohl für den Compiler als auch für den Leser. Ergo: Die Blockbegrenzer sind für die Richtigkeit, die Einrückungen für die Gefälligkeit beim Betrachter. So. W.S.
leo schrieb: > Nicht so hypothetisch O je. Es gibt doch wirklich nichts, das so bescheuert wäre, daß es nicht noch etwas NOCH BESCHEUERTERES gäbe. Naja: "Whitespace is an esoteric programming language"..... W.S.
Wenn Whitespace nichts ist - warum beschwert ihr euch gerade etliche Beiträge lang darüber?
W.S. schrieb: > 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 Programmiersprach Nein, der Nutzer muss einschätzen ob sein Problem mit dieserm Werkzeugt gut bearbeitbar ist. Die Diskussion ist immer die Gleiche. Ein Hammer ist super für einen Nagel. Scheiss Hammer, ich kann die Schraube nicht anziehen.... Oder wie beim Wein. Und wer der Spätburgunder noch so prämiert ist und alle trinken ihn nicht. Es ist nicht mein Fall. Ist er deshalb "schlecht oder kotzmiserabel"? Eine schlechte Programmiersprache wäre für mich eine, auf die man sich nicht verlassen kann. Erzeugt jedesmal andere Ausgaben...
W.S. schrieb: >> Nicht so hypothetisch > > O je. Es gibt doch wirklich nichts, das so bescheuert wäre, daß es nicht > noch etwas NOCH BESCHEUERTERES gäbe. Wie, soll das jetzt heißen, dass Whitespaces als Bestandteil der Syntax bescheuert wären? Also ich find die Idee witzig innerhalb eines Programms ein zweites unterzubringen. Sourcecode-Stenagographie!
Sorry für die Tippfehler: nochmal Oder wie beim Wein. Und wenn der Spätburgunder noch so prämiert ist und alle trinken ihn. Es ist nicht mein Fall. Ist er deshalb "schlecht oder kotzmiserabel"? Eine schlechte Programmiersprache wäre für mich eine, auf die man sich nicht verlassen kann. Erzeugt jedesmal andere Ausgaben...
Klaus schrieb: > Sorry für die Tippfehler: nochmal Tippfehler wurden beim Parsen aufgrund der Redundanz erkannt und korrigiert. Einrückungen und Zeilenumbrüche wurden ignoriert. Soll der korrigierte Text verwendet werden? J/N
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: > W.S. schrieb: >> Aber: Programmiersprachen bestehen aus Sprachelementen >> und diese müssen aus druckbaren Zeichen bestehen > > Warum? Weil umformatieren dann die Bedeutung nicht ändert -- und die Erfahrung lehrt, dass Text alle Nase lang aus den verschiedensten Gründen umformatiert wird. > Wo steht, dass Programmiersprachen die Formatierung > von Text ignorieren müssen? Wen interessiert, wo das steht? Die wichtige Frage ist, was sinnvoll ist.
Danke für da Feedback, Leo :-) Ich bin seit 41Tagen quasi ohne Schlaf (eine völlig neue Erfahrung). Wie ich die Zeilen geschrieben habe, hatte ich gerade eine Operation hinter mir und noch unter dem Einfluss der Narkose. Vielleicht siehst Du mir deshalb meine Fehltippereien nach. So was wird dir sicher nie passieren. Aber, wenn Du doch einmal auch über einen längeren Zeitraum bestialische Schmerzen hast, wirst Du Dich vielleicht an diese Zeilen erinnern.
Beitrag #6491987 wurde von einem Moderator gelöscht.
Beitrag #6492002 wurde von einem Moderator gelöscht.
Beitrag #6492015 wurde von einem Moderator gelöscht.
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.). Was
aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen
Quelltext sind. Ich persönlich hab die Einrückerei bei Spin (Propeller)
hassen gelernt und seitdem ist das Thema für mich erledigt (solang es
keiner im Beruf von mir fordert).
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. Mal vom Ardoino abgesehen. :-)
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. ;-)
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.
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.
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.
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.
Sheeva P. schrieb: > ... die allerdings nur eine ziemlich billige Ablenkung wäre, nicht wahr? Was du scheinbar nicht wirklich mitbekommen hast in dem Thread: Hier vertritt jeder seine Meinung wie in einem Glaubenskrieg. Beinahe jedes Argument lässt sich leicht umdrehen durch Ersetzungen. Gerade du tust dich jetzt als oberster Krieger hervor. Du kannst es nicht ertragen, dass Leute die objektiv unsinnige Tab / Space Einrückung eben nicht mögen. Nein, du bist besser als die Nicht-Pythons weil du das toll findest. Ich zeig euch (damit sind beide Seiten gemeint) nur auf, wie löchrig eure Argumente sind. Wenn ich Vorteile davon hätte, würde ich mich Python anfreunden können. Hab ich keine, darum mach ich aktuell was, was Andere total blöd finden werden: Ich schau mir OCaml an. Weil das eine Sprache mit einem völlig anderen Konzept ist. Für mich ist Python "just another scripting language". Und wenn du im Thread das 6. posting liest, steht da, dass jeder Softwareentwickler eine Scriptsprache können muss. Weder hab ich da geschrieben, dass das unbedingt Python sein muss, noch dass es keinesfalls Python sein darf. Das Problem ist eher die völlige Verblendung der pro-Python-Leute. Denn ansonsten hätte der Beitrag keine -5 Punkte. Lies selbst! Nick M. schrieb:
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?
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. 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. Und sieh das endlich ganz entspannt: Kaum einer (überhaupt jemand?) hat wirklich einen harten Grund genannt, warum Python untauglich ist. Python ist eine etablierte Sprache. Ich mag sie nicht, so wie C++ (das ich mal geliebt habe), oder Basic (damals gab es nichts anderes, als nächstes kam Pascal), oder Perl (da habich mal viel gemacht, bin aber immer wieder ins Schleudern gekommen), Assembler (es gibt C! Ausnahme 68000), you name it! Nick M. schrieb: > Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC > oder Arm. Kapiert?
W.S. schrieb: > Also nochmal zum Mitbuchstabieren: > 2. Blockbegrenzer (begin, end, {, }, oder sonstwas druckbares) sind > für das klare Abgrenzen von Blöcken - sowohl für den Compiler als auch > für den Leser. Ich hoffe Du Programmierst ausschließlich in Ada, Oberon und dergleichen. Also in Sprachen mit ENDIF, ENDFOR, END <function> usw. denn NUR mit solchen Blockbegrenzern wird klar welche Art von Blockabschluss gemeint ist. Mehrdeutige "END;"s (Pascal, M2), '}' (C*, Java), ')' (Lisp u.v.a.) bringen es einfach nicht, spätestens nach einer Refactoring-Session welche sich gewaschen hat. Das (back-)tracking dieser IST aufwändiger als das bisschen Einrücken von Py.Programmiersprachentheaterintendant
Nick M. schrieb: > Sheeva P. schrieb: >> ... die allerdings nur eine ziemlich billige Ablenkung wäre, nicht wahr? > > Was du scheinbar nicht wirklich mitbekommen hast in dem Thread: > Hier vertritt jeder seine Meinung wie in einem Glaubenskrieg. Was Du scheinbar nicht wirklich mitbekommen hast: genau das habe ich kritisiert und angelegentlich kritisch angemerkt, daß dieser Thread qua seiner Ausgangsfrage nicht der richtige Ort ist, seine Abneigungen zu erbrechen. > Gerade du tust dich jetzt als oberster Krieger hervor. Du kannst es > nicht ertragen, dass Leute die objektiv unsinnige Tab / Space Einrückung > eben nicht mögen. Das können die Leute meinetwegen gerne halten, wie sie wollen. Ob sie Python nutzen oder es hassen, ist mir vollkommen gleichgültig und insofern nicht mein Punkt. Mein Punkt ist, warum die Hasser ausgerechnet einen Thread hijacken und zumüllen müssen, in dem es NICHT um persönliche (Vor)Urteile und NICHT um die Frage geht, ob Python so beliebt ist, SONDERN um die Frage, WARUM es so beliebt ist. > Für mich ist Python "just another scripting language". Das stimmt ja auch, liefert aber keine Antwort auf die Frage des TO, warum Python so beliebt ist. Um ganz genau zu sein, hat es nichteinmal einen Bezug zu der Frage. > Lies selbst! > Nick M. schrieb: Äh... was jetzt genau?
Nick M. schrieb: > Ich schau mir OCaml an. Weil das eine Sprache mit einem völlig > anderen Konzept ist. Die Einstellung gefällt mir. "A language that doesn't affect the way you think about programming, is not worth knowing." Ich verstehe nicht warum einige der Meinung sind, dass sie mit ihren C++, Java und C#-Kenntnissen drei Programmiersprachen beherrschen. Aus meiner Sicht ist das nur eine ;-) Python ist halt eine gute Matlab // Mathematica // etc. Alternative. 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. Was zu Python pro Monat an Materialen rauskommt, liefert C doch in 5 Jahren nicht ;-)
Sheeva P. schrieb: > daß dieser Thread qua > seiner Ausgangsfrage nicht der richtige Ort ist, seine Abneigungen zu > erbrechen. Wo hab ich das gemacht? Sheeva P. schrieb: > Äh... was jetzt genau? Einfach auf den Link klicken. Mehr werde ich dir nicht vorkauen, denn dir fehlt es ganz offensichtlich an Objektivität.
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. Klar -- weswegen Du es auch gleich mal als "Schwachsinn" bezeichnen mußt. Weil Du (als einziger hier im Thread) das ja alles so völlig unemotional siehst. Natürlich hättest Du schreiben können, daß Dir das mit den Einrückungen nicht gefällt, weil Dir die Erfahrung mit einer Sprache nicht gefallen hat, die das ähnlich macht. Aber Du mußtest stattdessen auf die Kacke hauen und das einfach mal als "Schwachsinn" abtun -- und behauptest jetzt, das sei alles ganz unemotional und alle (außer Dir, natürlich) würden hier einen Glaubenskrieg führen. > 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. Sag' es doch einfach, anstatt Deinem Gegenüber zu unterstellen, es könne nicht lesen. Nebenbei ließe sich Rolfs großartige Frage noch erweitern um die Frage, warum sich hier irgendwelche Leute mit schärfsten Ausdrücken über eine Sprache echauffieren, die sie niemals genutzt haben und nicht nutzen wollen, weil sie sie hassen? > Und sieh das endlich ganz entspannt: > Kaum einer (überhaupt jemand?) hat wirklich einen harten Grund genannt, > warum Python untauglich ist. Nein, einen solchen Grund hat keiner genannt, und abgesehen davon, daß es einen solchen Grund weder gibt (und bei einer so weit verbreiteten Sprache sicher auch nicht konstruiert werden kann), wären auch solche Aussagen hier deplatziert. > Python ist eine etablierte Sprache. Richtig. > Nick M. schrieb: >> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC >> oder Arm. > > Kapiert? Nicht auch noch patzig werden, ja? Und: meine Anregung war und ist ja, einfach nur die Frage des TO zu beantworten, warum Python so beliebt ist. Zu einem Glaubens- und Sprachenkrieg machen das nur die Leute, die Python nicht kennen, es trotzdem aus irgendwelchen "Gründen" hassen und es deswegen offensichtlich nicht ertragen können, daß hier jemand etwas positives über die Sprache und seine Erfahrungen damit sagt.
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? Merkst du das nicht selbst, dass das einfach kein Argument ist zu sagen: Alle finden es toll. Klar gibt es aktuell weniger neue Bücher zu C. Das ist von 1972. Und es wurde fast schon alles von fast schon jedem gesagt. Bei Python muss halt fast jeder noch fast alles sagen. So kann er seine Bücher verkaufen, kann sich im I-Net profilieren und alle können sich gegenseitig bejubeln und über die Idioten herziehen die formatierungsabhängige Sprachen bekloppt finden. Ich glaub sogar, dass D. Knuth die auch bekloppt findet. Was mich aber nicht besser macht.
Nick M. schrieb: > Sheeva P. schrieb: >> daß dieser Thread qua >> seiner Ausgangsfrage nicht der richtige Ort ist, seine Abneigungen zu >> erbrechen. > > Wo hab ich das gemacht? Beitrag "Re: was ist das besondere an der programmiersprache Python?" > Sheeva P. schrieb: >> Äh... was jetzt genau? > > Einfach auf den Link klicken. Ach, daß es verschiedene Vorlieben gibt? Ein Allgemeinplätzchen ohne Aussagewert. > Mehr werde ich dir nicht vorkauen, denn dir fehlt es ganz offensichtlich > an Objektivität. Also muß man Python hassen, damit es für Dich hinreichend objektiv ist?
Und im Übrigen bin ich der Meinung, dass Karthago... ähm die Anzahl der
Programmiersprachen stark begrenzt werden soll.
Kann man nicht einen Interpreter für C++ schreiben, der Berechnungen wie
bei Matlab ermöglicht? Natürlich kann man das. Mit einer C++-Syntax.
dann sehen alle Schleifen / Vergleiche überall gleich aus.
Und nicht so, dass
- da schließe ich alle Anweisungen mit ; ab, hier aber nicht
- da begrenze ich die Funktionen durch {}-Klammer, hier aber durch die
Einrückung
- usw..
Das ist doch Schwachsinn! Die Schreibweise muss langsam vereinheitlicht
werden.
Die Informatiker sollen aufhören die Synthax zu verändern, sondern sich
an den Kern wagen.
Stellt euch vor die Mathematiker, Physiker, Chemiker und Ingeneure
würden für ihre Berechnungen unterschiedliche Zahlendarstellungen
benutzen! Der Turmbau zu Babel hat doch keine Zukunft.
Dutzende neue Sprachen pro Jahr - das ist krank.
Sheeva P. schrieb: > Nicht auch noch patzig werden, ja? Ja Glaubenskrieger! Python ist einfach die Sprache der Herrschenden. Alle Anderen sind unterlegen. Alahu Agbar! Sheeva P. schrieb: > Sag' es doch einfach, anstatt Deinem Gegenüber zu unterstellen, es könne > nicht lesen. So wirds wohl sein mit dem nicht lesen können, denn es wurde nachweislich mehrfach erklärt. Kann man aber überlesen, wenn man voller Hass auf die Andersgläubigen ist. Ansonsten wünsch ich besonders dir, oh großer Kämpfer für die einzige wahre Programmiersprache die erfolgreiche Niederschlagung all der Idioten die nicht deiner einzigen und gottgegebenen Sprache hörig sind die totale Welteroberung. Ich häng mich derweil im vorauseilenden Gehorsam untertänigst auf.
Beitrag #6492383 wurde von einem Moderator gelöscht.
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag #6492372: > Dutzende neue Sprachen pro Jahr - das ist krank. und jede hat andere Kommentarzeichen - zum kotzen https://de.wikipedia.org/wiki/Kommentar_(Programmierung)
Ich nutze Python schon seit über 20 Jahren, als die Sprache zwar schon
geraume Zeit existierte, aber noch weit entfernt vom Mainstream war.
Kurz: Ich war schon von Anfang an davon absolut begeistert, und seither
entwickelte sich Python fast nur zum Positiven. IMHO spielt die Sprache
inzwischen völlig zurecht in der obersten Liga und hat sich den Weg
dorthin langsam, aber stetig erkämpft. Von einem Hype kann da überhaupt
keine Rede sein.
Python hat eine ganze Reihe von Vorteilen, die in Kombination die
Sprache zu einer sehr runden Sache machen:
- Es ist leicht erlernbar:
- relativ geringer Sprachumfang
- einfache Syntax mit vielen "sprechenden" Schlüsselwörtern
- sozusagen das bessere und modernere Basic
- Es lässt sich interaktiv nutzen:
- auf die Schnelle etwas testen, ohne eine Quellcodedatei editieren
und kompilieren zu müssen.
- sehr vorteilhaft beim Erlernen der Sprache
- Es ermöglicht kurzen, knackigen und dennoch gut lesbaren Quellcode:
- wenig Redundanz (Boilerplate):
- durch dynamische Typisierung weitgehender Verzicht auf
Deklarationen
- Verzicht auf Blockklammern (korrekte Einrückung genügt)
- ausdrucksstark:
- häufig genutzte Container-Datentypen (List, Tuple und Dictionary)
sind fester Bestandteil der Sprache und werden durch syntaktische
Mittel stark unterstützt:
- List-Comprehensions
- mehrere Indizierungsmöglichkeiten
- Extraktion von Teilen der Container
- komfortables Entpacken in Einzelvariablen
- Iteration über Container-Elemente ohne Schleifenindex
- Lambda-Ausdrücke zur Inline-Definition einfacher
Callback-Funktionen u.ä.
- Generatoren erlauben u.a. die Entflechtung stark verschachtelter
Schleifenkonstrukte
- mächtige und dennoch leicht zu nutzende Standardbibliothek
- Es bietet gute Unterstützung bei der Integration von und in
sprachfremden Code:
- einfache Einbindung bestehender C-Bibliotheken in Form von shared
Libraries bzw. DLLs bspw. mit dem ctypes-Modul
- einfache Integration von Python in andere Programme, bspw. als
Scripting-Schnittstelle für Plugins
- Es gibt dafür sehr guten Support:
- umfangreiche Standardbibliothek
- gute und auch für Einsteiger verständliche Dokumentation
- große Community mit einer schier unendlichen Menge an weiteren
Bibliotheken
- evtl. auftretende Fragen und Probleme sind mit fast sicher schon auf
stackoverflow.com beantwortet bzw. gelöst worden
Das alles führt zu
- kurzen Entwicklungszeiten im Vergleich zu klassischen Sprachen wie
bspw. C++
- mehr Spaß beim Programmieren
Viele der genannten Vorteile treffen auch für andere Programmiersprachen
zu, aber keine der mir bekannten vereint sie alle unter einem Hut.
Diesen Vorteilen stehen natürlich auch einige Nachteile gegenüber:
- geringe Redundanz (s.o.) ist nicht nur ein Vorteil:
- viele Programmierfehler werden erst zur Laufzeit aufgedeckt und dort
manchmal erst nach längerem Einsatz -> systematischer Softwaretest
ist essentiell (sollte es aber auch in anderen Sprachen sein)
- das Fehlen von Blockklammern verhindert eine automatisierte
Neuformatierung bei kaputt gegangenen Einrückungen
- oft geringe Ausführungsgeschwindigkeit
- in der Standardimplementation nur ein Bytecode- aber kein
Native-Code-Compiler vorhanden
- im Vergleich zu vielen anderen Interpretersprachen recht schnell,
aber langsam im Vergleich zu kompilierten und statisch typisierten
Sprachen wie C++
- hardwarenahe und Echtzeitprogrammierung nicht bzw. nur sehr
eingeschränkt möglich
- durch leichte Rekompilierbarkeit des Bytecodes unzureichender
IP-Schutz
Für mich persönlich überwiegen die Vorteile von Python dessen Nachteile
in gefühlten 80% der von mir entwickelten Software bei weitem. Vielen
anderen Softwareentwicklern geht es wohl ebenso, sonst würde Python in
den Statistiken nicht so weit oben stehen.
Insbesondere die von einigen immer wieder lautstark hervorgebrachte
Kritik am Einrückungszwang ist für mich überhaupt nicht nachvollziehbar,
erst recht nicht, seit in Python 3 die Regeln für das Mischen von Tabs
und Spaces dahingehend verschärft wurden, dass – unabhängig vor der
Tab-Weite – die visuell wahrgenommene Blockstruktur immer auch der
syntaktischen entspricht. Von mir aus könnten die Tabs aber auch
komplett aus der Sprache verbannt werden. Auch Guido van Rossum hat wohl
mittlerweile eingesehen, dass – ähnlich wie in YAML – Tabs in Python nur
Kopfschmerzen bereiten und würde sie verbieten, wenn er die Sprache noch
einmal entwickeln würde.
Selbst wenn ich eine Software in C++ entwickle, nutze ich sehr oft
Python, um bei damit prototypisch erst einmal verschiedene Konzepte und
Algorithmen durchzuprobieren, bevor ich mich für eine bestimmte Option
entscheide. Dies spart am Ende Entwicklungszeit und führt zu qualitativ
besseren C++-Code, weil dieser dann sozusagen schon in der Version 2
vorliegt.
In Verbindung mit Numpy, Scipy und Matplotlib ist Python für mich auch
ein kostengünstigerer und flexiblerer Matlab-Ersatz. Bei numerischen
Algorithmen mit größeren Datenmengen, die auf Vektoren und Matrizen
abgebildet werden können, liegt damit die Ausführungsgeschwindigkeit
i.Allg. nicht arg viel niedriger als in C++.
Für Bildverarbeitung nutze ich intensiv die OpenCV-Bibliothek, die von
Hause aus C++ und Python unterstützt. Da im Bereich der Bildverarbeitung
naturgemäß viel experimentiert werden muss, kommen hier die Vorteile von
Python voll zum Tragen. Da fast alle rechenintensiven Operationen durch
die Bibliothek abgewickelt werden, ist auch hier die Geschwindigkeit
kaum unter der von C++. Stellt die OpenCV einen bestimmten Algorithmus
nicht zur Verfügung (was recht selten der Fall ist) und ist er auch mit
Numpy-Mitteln nicht effizient implementierbar, schreibe ich ihn in C
oder C++ und binde ihn als shared Library in das Python-Programm ein.
Schließlich verwende ich Python auch als hochentwickelten Taschenrechner
auf dem PC.
Python lässt sich auch als Plugin-Sprache in vielen Anwendungen (bspw.
Gimp, Inkscape, Vim usw.) nutzen und ist damit sozusagen das VBA für
Nicht-Microsoft-Anwendungen.
Vom Grundkonzept her ganz ähnlich zu Python ist die Sprache Ruby,
allerdings ist dort das Angebot an Bibliotheken und der Support durch
die Community nicht ganz so gut.
Bleibt noch Perl, das ebenfalls viele Dinge mit Python gemeinsam hat und
ebenfalls eine sehr große Community hat. Ein Vorteil von Perl gegenüber
Python ist die Integration von regulären Ausdrücken in den Sprachumfang
(in Python gibt es sie nur als Bibliothek). Das ist dann interessant,
wenn man viel Textanalyse machen möchte. Ansonsten ist mir Perl einfach
etwas zu altbacken, was sich bspw. in der Art und Weise äußert, wie
Funktionsargumente innerhalb einer Funktion entgegengenommen werden.
Rolf M. schrieb: > 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? Du bist ein wenig starrsinnig, denn es wurde dir bereits mehrfach im Detail erklärt. Hier geht es um das Fehlen der Blockmarkierungen und den Ersatz selbiger durch das fehlerträchtige Maß von Einrückungen. W.S.
Ich versuch’s mal mit dem Threadthema: osman schrieb: > Kann jemand erklären, was ist das besondere an der programmiersprache > Python? Es ist eine einfache, leicht zu erlernende und leicht zu lesende, dabei aber umfassend ausgestattete, Sprache. Die Doku ist ausgezeichnet, alleine schon mit dem Tutorial auf deren Seite kann man ziemlich schnell ziemlich beeindruckende Sachen erstellen. Ziemlich gute IDEs, die dabei unterstützen, (z.B. Pycharm) sind verfügbar; es gibt aber auch ein shellartiges CLI mit Syntaxhighlighting und Autocomplete (ipython). Die meisten Editoren mit Fokus auf das Programmieren/Scripten bringen Funktionalität zur Nutzung von Python mit. Schnittstellen zu den großen UI-Toolkits (Gtk, Qt) sind vorhanden und ausgereift, so dass man auch mit wenig Aufwand grafische Programme schreiben kann. Schnittstellen zu den verbreiteten DBMS sind ebenfalls vorhanden, selbst ein integrierter Webserver fehlt nicht. Virtuelle Environments und ein integriertes Paketmanagementsystem mit schier grenzenloser Auswahl machen es extrem einfach, sich ein Setup für ein konkretes Projekt zusammenzustellen, ohne an der eigentlichen Installation rumpfuschen zu müssen. Der größte Posten des Preises für das alles, und viel mehr, ist der Ressourcenverbrauch und die geringe Ausführungsgeschwindigkeit. Um das zu kompensieren, kann man auf Schnittstellen zu C/C++ zurückgreifen, und zeitkritische oder auf andere Art rechenintensive Aufgaben etwa als Module dahin auszulagern, um vom eigentlichen Programm aus bequem darauf zuzugreifen. Auch gibt es Ansätze, mit denen sich Scripte kompilieren lassen. Typischerweise sind Pythonscripte gemessen an ihrer Funktionalität extrem kurz, und bleiben dabei lesbar (ich habe damals™ einen modularen IRC-Bot in weniger als fünfzig Zeilen implementiert, und konnte das nach mehreren Jahren immer noch einwandfrei selbst lesen) Bei all dem ist die Sprache weitgehend portabel, es ist also recht einfach, Software damit zu erstellen, die sowohl unter Linux, als auch unter Windows, als auch unter BSD, als auch unter MacOS läuft, als auch unter AIX, als auch unter den anderen unter https://www.python.org/download/other/ aufgeführten Systemen läuft. Aufgrund der oben genannten Eigenschaften (und vielen mehr) hat sich die Sprache weit verbreitet; es gibt eine riesige Community, in der man für eigentlich jedes Problem Unterstützung bekommen kann.
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag
#6492356:
> Was zu Python pro Monat an Materialen rauskommt,...
Unsereiner kriegt pro Monat so ungefähr einen Zentner an Werbung ins
Haus. Meinst du, das ist relevant - mal abgesehen von all den dafür
abgeholzten Wäldern?
W.S.
Beitrag #6492406 wurde von einem Moderator gelöscht.
19 Millionen können nicht irren. :-)) Google: "python indentation" Ungefähr 19.800.000 Ergebnisse (0,51 Sekunden) Yalu, dir widerspricht doch keiner grundlegend. Nur, was du sagst gilt auch für andere Scriptsprachen. Einschließlich der Nachteile. Ich ersetzte einfach Python mit Tcl und streich den Satz mit der Einrückung. Ersetze ihn aber mit den schwachsinnigen Kommentaren in Tcl. Das ist nämlich gleich dumm wie die Einrückung in Python. Ich sags nochmal, auch wenn es der User Sheeva wieder geflissentlich überliest: Es hängt im Wesentlichen davon ab, in welchen Umfeld du dich bewegst ob Scriptsprache X oder Y besser ist (oder als besser empfunden wird). Ein Vergleich mit C, C++, Java ist nicht zielführend, weil das compilierte Sprachen sind.
Nick M. schrieb: > schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag > #6492356: >> Außerdem machen die ihre Angebote gleich sehr attraktiv (wie bei Rust). >> Da gibt es eigene Webseite mit Tutorials, kostenlosen Büchern, >> kostenlosen IDE's und Plugins für für verschiedene Editoren // IDE's. Es >> werden STÄNDIG neue Bücher veröffentlicht. Neue Libs werden geschrieben >> / portiert. Und, und, und. > > Dürfte man das ganz vorsichtig als Hype bezeichnen? Das kann man jederzeit unter diesem Aspekt betrachten, müßte aber bei Python sehr schnell feststellen, daß das keineswegs ein Hype, sondern so eine Henne-Ei-Sache ist. Eine fast dreißig Jahre alte Programmiersprache, die sich im Laufe der letzten zehn, zwanzig Jahre zur beliebtesten, verbreitetsten und erwünschten Sprache zu bezeichnen, wird der Sache nicht gerecht, denn ein Hype (oder genauer: ein Medienhype) ist doch gemeinhin eine eher kurzfristige Angelegenheit und würde bedeuten, daß das solcherart "gehypte" ähnlich schnell wieder verschwände, wie es aufgetaucht ist. Python ist aber nicht schnell aufgetaucht, und seine Beliebtheit ist das Ergebnis von vielen Jahren einer stetigen Entwicklung, während der es sogar einige etablierte und eingesessene Platzhirsche wie Perl verdrängt, andere wie PHP stark unter Druck und sich gegen Wettbewerber wie Ruby durchgesetzt hat. Von einer Kurzfristigkeit, wie Du sie mit dem Begriff "Hype" insinuierst, ist jedoch im Zuge der Entstehung der aktuellen Situation -- wie gesagt: Python ist aktuell die beliebteste, verbreitetste und meistgewünschte General-Purpose-Skriptsprache der Welt -- also nichts zu sehen, und vom -- durch den Begriff "Hype" ebenfalls unterstellten -- baldigen Abflauen des Aufwärtstrends von Python ist bisher jedenfalls auch nichts zu erkennen. Tatsächlich ist es aber so, daß Python nunmal aktuell die beliebteste, verbreitetste und meistgewünschte General-Purpose-Skriptsprache der Welt ist und es im Moment auch keinen einzigen Hinweis darauf gibt, daß sich daran so bald etwas ändern wird. Diese Umstände haben Folgen, und zwar vor allem, daß immer mehr Entwickler sich für die Sprache interessieren und deswegen Bibliotheken dafür entwickeln. Andere schreiben Bücher darüber und bieten Kurse, Tutorien oder anderes an. Klar: wenn man sagen will, daß das nur die aktuelle Kuh sei, die durch das Dorf getrieben werde, bald wieder verschwände, und es deswegen unnötig sei, sich mit dem Thema zu beschäftigen: ja, dann kann man das als Hype bezeichnen, vorsichtig oder auch unvorsichtig, ganz nach Belieben. Aber wenn man das tut, wird man leider damit leben müssen, daß es dem, was einen Hype ausmacht, nicht ansatzweise entspricht, und das man deswegen Widerspruch erntet und eines Besseren belehrt wird. Du sagst, Python sei "just another scripting language", und das simmt natürlich auch. Wie jede andere Skriptsprache hat es gewisse Eigenschaften und Eigenarten, welche man gut -- für sich persönlich -- gerne oder schlecht finden kann. Aber das erklärt weder, warum Du es unbedingt zu einem Hype kleinreden willst, noch seinen grandiosen Erfolg, um den es -- langsam komme ich mir vor wie eine tibetanische Gebetsmühle -- in diesen Thread geht. Verstehst Du, was ein Thema ist? Außerdem ist Python ganz besonders stark in einem Bereich, den es tatsächlich schon lange gibt, der aber in den letzten Jahren besonders populär geworden ist und daher schon eher den Kriterien eines Hype entspricht. Nämlich der Verarbeitung, Analyse und Visualisierung von Massendaten, Stichworte: Big Data, Machine Learning, und Data Science. Und weil in den letzten Jahren immer mehr Anwendungsfälle den Weg in die praktische Anwendung gefunden haben und aktuell vielle Entwicklungen sowohl in der Wissenschaft, als auch in der Industrie und dem OSS-Umfeld stattfinden, gewinnt auch das damit eng verbundene Python weitere hohe Aufmerksamkeit, die ihm und seiner weiteren Verbreitung natürlich ebenfalls zuträglich ist. Du hast etwas weiter oben geschrieben, eine Sprache stünde oder fiele mit ihren Bibliotheken. Auch das ist richtig, und genau das einer der wichtigsten Gründe für den großen Erfolg von Python. Tatsächlich ist es umgekehrt aber genau diese große Vielfalt an leistungsfähigen, ausgereiften, aufeinander abgestimmten Bibliotheken (nebst weiteren Tools), die wesentlich zum enormen Erfolg von Python beitragen und zweifellos auch dafür sorgen, daß es kein Hype war, ist, oder wird. Und dabei ist es vor allem die Vielfalt von gut aufeinander abgestimmten Bibliotheken, die Pythons allergrößte Stärke darstellt. Vergleichbare Sprachen sind in der Regel nur in einer Domäne stark, PHP und Ruby zum Beispiel für die Webentwicklung. Es gibt zwar GUI-Frameworks und auch Bibliotheken für die Datenanalyse für diese beiden, aber nichts davon ist auch nur im Ansatz so ausgereift wie die verfügbaren Erweiterungen für Pyton. Perl ist zwar ein echter Allrounder, tut sich aber wie Ruby keinen Gefallen damit, Regular Expressions in den Sprachkern zu integrieren und Sonderzeichen zur Variablenauszeichnung zu benutzen, was die Lesbarkeit des Quellcode einschränkt. Die Antwort mancher Entwickler auf die verschiedenen Stärken und Schwächen ihrer Sprachen bringen manche Entwickler dazu, sich für jede Problemstellung und jeden Anwendungsfall eine eigene Sprache, deren eigene Infrastrukturen, und eine eigene IDE anzueignen. Klar, das kann man so machen. Mein Ansatz hingegen ist ein anderer: ich suche mir darum eine Sprache, die alles, was ich heute oder (soweit absehbar) in Zukunft machen möchte, gleichermaßen sehr gut beherrscht. Genauso wie ich einen Editor (oder einen Editor mit eingebauten Betriebssystem und eigener Programmiersprache, oder eine IDE) benutze, der mit dieser und mit allen anderen Sprachen gleichermaßen gut umgehen kann. Ich habe meine Wahl getroffen. Meine Skriptsprache hieß früher Perl, heute heißt sie Python, und mein Editor / IDE heißt GNU Emacs. Damit bin ich äußerst zufrieden, die Arbeit damit ist produktiv und macht mir erfreulicherweise zudem auch noch Spaß. Wer das nicht mag, soll eben was anderes nehmen. Muß ich das verstehen? Nein. Muß ich es akzeptieren? Aber ja, natürlich -- schon weil es mich nichts angeht. ;-)
Nick M. schrieb: > Sheeva P. schrieb: >> Nicht auch noch patzig werden, ja? > > Ja Glaubenskrieger! Python ist einfach die Sprache der Herrschenden. > Alle Anderen sind unterlegen. > Alahu Agbar! Schon lustig, wie angepiekt Du auf sachlichen Widerspruch reagierst. > Kann man aber überlesen, wenn man voller > Hass auf die Andersgläubigen ist. Da muß ich mich auf Dein geschätztes fachmännisches Urteil verlassen, damit kenne ich mich nicht aus und lege auch keinen Wert darauf, Erfahrung damit zu sammeln. > Ich häng mich derweil im vorauseilenden Gehorsam untertänigst auf. Laß mal, hinterher muß irgendein bedauernswerter Mensch die Sauerei wegmachen. Mir persönlich würde es schon reichen, wenn Du endlich einmal anfangen würdest, Dich wie ein Erwachsener zu benehmen und sachlich zu diskutieren, statt immer wieder mit diesen kindischen Ausfällen zu nerven in der Hoffnung, das würde mich beeindrucken.
Yalu X. schrieb: > [...] Wow, ein hervoragener Beitrag, der die Frage des TO vollständig beantwortet und es auch ansonsten perfekt auf den Punkt bringt. Danke!
Fast jeder kann Python schreiben, lesen quasi jeder, der man programmiert hat. Es ist extrem breit gefächerten, von einfachem Glue code über dicke Maschinen Lernen libs zu guter Visualisierung und GUI Anbindungen. Jeder Entwickler sollte ne Skriptsprache können imo, Python ist da einfach gut geeignet, weil man (im Gegenzug zur Standard bash zb) auch komplexer werdenden Probleme schön in den Griff bekommt. Habt immer die Praxis im Hinterhof! Fast alle ci/cd Umgebungen unterstützen Python, es gibt bereits fertige Module für Anbindungen zu gitlab, bitbucket, GitHub, egal was du willst. Auf Geschwindigkeit kommt es fast niemals an. PS, stark typisieren kann man mittlerweile per pypy auch. Für scientific computing gucke ich mir aber gerade Julia an. Auch sehr interessant :)
Sheeva P. schrieb: > Yalu X. schrieb: >> [...] > > Jack V. schrieb: >> [...] Wow, zwei hervorragende Beiträge, die die Frage des TO vollständig beantworten und es auch ansonsten perfekt auf den Punkt bringen. Danke!
Sheeva P. schrieb: > Du sagst, Python sei "just another scripting language", und das simmt > natürlich auch. Wie jede andere Skriptsprache hat es gewisse > Eigenschaften und Eigenarten, welche man gut -- für sich persönlich -- > gerne oder schlecht finden kann. Und jetzt? Hab ich jemals was anderes gesagt? > Aber das erklärt weder, warum Du es > unbedingt zu einem Hype kleinreden willst, Ich will es nicht kleinreden. Und verdammt nochmal LIES was ich geschrieben hab. Und zwar bis zum Ende des jeweiligen Beitrags. Und pick nicht den einzigen Satz dabei raus, der dir, oh du großer Evangelist der besten und einzigen Programmiersprache ... > langsam komme ich mir vor wie eine tibetanische > Gebetsmühle -- in diesen Thread geht. Keine Angst, du bist was du bist. Ein Leierkasten (muss nicht aus Tibet sein), der nur seine Meinung zulässt und die wahre Sprache gefunden hat. Stehst du auch immer an der gleichen Ecke und hältst den Wachturn der wahren Sprache Python hoch? Ich bin nur ein kleiner Sünder. Ja eine Hure sogar, die die Sprache verwendet die ihm gerade gefällt. Lass mich mal aufzählen: Basic, Pascal, Modula-2, Oberon, Eiffel, C, C++, ObjC, Fortran, Div. Assembler, Tcl, Perl, fehlen bestimmt noch paar. Das heißt nicht, dass ich die Sprachen noch kann! Ich bin kein Genie. > Verstehst Du, was ein Thema ist? Nö! Du? Warum regst du dich den (nach deinen Regeln) anhaltend völlig offtopic über andere Meinungen auf? > Ich habe meine Wahl getroffen. Andere auch. > Meine Skriptsprache hieß früher Perl, Meine auch. Aber vorher AWK. > heute heißt sie Python, Meine Tcl > und mein Editor / IDE heißt GNU Emacs. Je nachdem, aufm Mac eigentlich immer Sublime, auf Win oft Notepad++ oder halt der Editor von MPLAB X oder Quartus. Ich bin da nicht so verbohrt. Ist mir eher wurst, alle taugen was und manchmal nehm ich halt den ganz speziellen, der das als einziger kann. Ist wie mit den Sprachen oder den Prozessoren. Wenn mir was zu schwachsinnig ist, nehm ich was mit erträglichen Schwachsinn. Ist aber auch völlig egal, welchen Editor du verwendest, welch Scriptsprachen du nicht mehr magst und wie es dazu gekommen bist, dass du dich für etwas entschieden hast. Das gibt schon so viele Permutationen, dass es reichlich wenig werden die dir unabdingbar zujubeln werden. Der Rest deines Neuen Testaments ist wohl nicht lesenswert. Zumindest waren deine Vorherigen Posts schon zweifelhaft genug.
Beitrag #6492484 wurde von einem Moderator gelöscht.
Nick M. schrieb: > Yalu, dir widerspricht doch keiner grundlegend. Das würde ich auch keinem raten ;-) > Nur, was du sagst gilt auch für andere Scriptsprachen. Einschließlich > der Nachteile. Nur dass IMHO Python mehr Vorteile und weniger Nachteile in sich vereint als andere Programmiersprachen. Dennoch ist natürlich auch Python nicht perfekt, und was für den einen ein Vorteil ist, kann von einem anderen als Nachteil wahrgenommen werden. > Ich ersetzte einfach Python mit Tcl und streich den Satz mit der > Einrückung. Ersetze ihn aber mit den schwachsinnigen Kommentaren in Tcl. > Das ist nämlich gleich dumm wie die Einrückung in Python. Naja, zumindest die Syntax von Tcl ist im Vergleich zu Python ja schon ziemlich primitiv und unelegant. Sie erinnert mich stark an eine Shell-Sprache, mit ich ungern größere Softwareprojekte realisieren würde, auch wenn das prinzipiell natürlich möglich ist. Aber das ist natürlich bis zu einem gewissen Grad Geschmackssache. Weiter oben schrieb ja jemand, dass er auch Python nicht für große Projekte geeignet hält. > Ich sags nochmal, auch wenn es der User Sheeva wieder geflissentlich > überliest: Es hängt im Wesentlichen davon ab, in welchen Umfeld du dich > bewegst ob Scriptsprache X oder Y besser ist (oder als besser empfunden > wird). In diesem Punkt sind wir einer Meinung. Ich wollte mit einem obigen Beitrag Python auch nicht als die objektiv beste Programmiersprache propagieren, sondern die Vorteile aufzählen, die vermutlich der Grund für die ständig steigende Akzeptanz der Sprache sind. > Ein Vergleich mit C, C++, Java ist nicht zielführend, weil das > compilierte Sprachen sind. Warum nicht? Solange ein Programm tut, was es soll, und ausreichend flüssig läuft, interessiert es mich als Entwickler wenig und den Anwender überhaupt nicht, ob der Quellcode direkt interpretiert wird, vorher in einen Bytecode übersetzt wird, zur Laufzeit vielleicht noch einen JIT-Compiler durchläuft oder direkt in Native-Code übersetzt wird. Als es für Java noch keinen JIT-Compiler gab, wurde – genauso wie in Python – der Quellcode beim Entwickler in Bytecode kompiliert, der dann beim Anwender durch einen Bytecode-Interpreter ausgeführt wurde. Mittlerweile kann sowohl Java als auch Python in Nativ-Code überführt werden. Insofern ist die Kompilierbarkeit kein Kriterium für die Sinnhaftigkeit des Vergleichs zwischen zwei Programmiersprachen. Für mich besteht zwischen C++ und Python durchaus ein Konkurrenzkampf, der in meiner kleinen Welt nicht immer, aber immer öfter von Python gewonnen wird.
Yalu X. schrieb: > Warum nicht? Weil compilierte Sprachen vorher einen Check machen können. In Scriptsprachen kann man genialen Unsinn anstellen. Der entweder als Unsinn endet, oder tatsächlich genial ist. In Tcl sieht das bsp. so aus:
1 | proc Proc1 { num } { |
2 | puts "Proc $num" |
3 | }
|
4 | |
5 | proc Proc2 { num } { |
6 | puts "Proc $num" |
7 | }
|
8 | |
9 | for {set i 1} {$i < 3} {incr i} { |
10 | Proc$i $i |
11 | }
|
Die Schleife wird Proc1 und Proc2 aufrufen. Genauso kann man auch auf Variablen zugreifen. Und so ein typloser zusammengepappter Code lässt sich zur Compilezeit nicht überprüfen. Daher der Punkt in deiner Nachteils-Liste mit den Fehlern. Genau daher mag ich Skriptsprachen. Aber gleichzeitig kann man sich damit ganz elegant ins Bein schießen. Wenn sowas im Hause bleibt, ist das kein Problem. Warum das aber ausgeliefert ein übler Angriff gegen die eigene Firma sein kann versuch ich nicht nochmal zu erklären. Zu deinen anderen Punkten hab ich nicht wirklich was zu widersprechen.
Beitrag #6492505 wurde von einem Moderator gelöscht.
[Anm. d. Mod.: geloescht] Sheeva P. schrieb im Beitrag #6492505: > Trotzdem muß ich > widersprechen, denn: einer meiner wesentlichen Gründe für die Wahl von > Python war, daß es eben tatsächlich ein starker Allrounder ist. Ohne > Python würde ich Meß- und Massendaten wohl mit R verarbeiten, meine > Automatisierungen (immer noch) in Perl machen, FatClient-GUIs in C++ mit > Qt oder ebenfalls Perl, und Webapplikationen mit PHP oder Ruby (on > Rails) entwickeln. Hättest alles auch mit Tcl/Tk machen können. Das heißt aber weder das Eine, noch das Andere. Sind halt nur wieder ein Haufen Wörter von dir die letztendlich kein Argument sind. Weder für das Eine nach das Andere. Oder soll ich jetzt den Code für meinen LXI-Abfrage hier posten um irgendwas zu belegen. Wäre aber mit Tcl/Tk und hat hier nichts verloren. Hypothetisch: Mit den LXI-Daten bereite ich dann eine Datei für GNU-Plot auf und ruf dann Gnuplot auf. Also ist da auch gleich Automatisierung dabei. UI ist mit Tk. [Anm. d. Mod.: geloescht]
:
Bearbeitet durch Admin
Beitrag #6492530 wurde von einem Moderator gelöscht.
Sheeva P. schrieb im Beitrag #6492505:
> Aber zum Glück muß ich das nicht.
Eben. Darum braucht wir EINE Programmiersprache für alles.
Und Python ist dafür natürlich nicht geeigent ;-)
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag #6492532: > Und Python ist dafür natürlich nicht geeigent Deinem Nick nach codest du in Teuton (http://www.fiber-space.de/EasyExtend/doc/teuton/teuton.htm)? [scnr]
Beitrag #6492560 wurde von einem Moderator gelöscht.
Beitrag #6492563 wurde von einem Moderator gelöscht.
Yalu X. schrieb: > Naja, zumindest die Syntax von Tcl ist im Vergleich zu Python ja schon > ziemlich primitiv und unelegant. **SCHNIPP** > Aber das ist natürlich bis zu einem gewissen Grad Geschmackssache. Ja, was sag ich dazu? **Schulterzucken** Dir gefällt die Syntax nicht, ich finde sie anfangs verwirrend und daher eine Herausforderung. Ist schon ziemlich gaga was man in Tcl in einer Zeile schreiben kann. Das hat aber auch damit zu tun, ob man leserlichen code schreiben will oder nicht. Ist wie mit C und dem Obfuscated C-Contest. Was da rauskommt versteh ich nicht, will ich aber auch nicht verstehen. Ist mir zu mühsam. Andere finden es lustig. Auch OK. Ich finde sowas leserlich, so schreib ich Tcl
1 | foreach lineDict $::flawDrawLayout { |
2 | |
3 | if {[dict get $lineDict visible]} { |
4 | incr atY [dict get $lineDict height] |
5 | |
6 | set displayEngineToCall "" |
7 | append displayEngineToCall [dict get $lineDict engine] "::DataDisplay" |
8 | # Does that PB use and need engineSettings?
|
9 | if {[dict exists $lineDict engineSettings]} { |
10 | $displayEngineToCall $::canvasSignals $atY [dict get $lineDict dataSource] [dict get $lineDict engineSettings] |
11 | } else { |
12 | $displayEngineToCall $::canvasSignals $atY [dict get $lineDict dataSource] |
13 | }
|
14 | |
15 | incr atY 6 |
16 | }
|
17 | }
|
Natürlich ist das Geschmackssache! Darum geht es doch schon die ganze Zeit! Was fehlt ist die Anerkennung, dass es verschiedene Geschmäcker gibt.
[Anm. d. Mod: Abschnitt geloescht] > Sheeva P. schrieb im Beitrag #6492505: >> Trotzdem muß ich >> widersprechen, denn: einer meiner wesentlichen Gründe für die Wahl von >> Python war, daß es eben tatsächlich ein starker Allrounder ist. Ohne >> Python würde ich Meß- und Massendaten wohl mit R verarbeiten, meine >> Automatisierungen (immer noch) in Perl machen, FatClient-GUIs in C++ mit >> Qt oder ebenfalls Perl, und Webapplikationen mit PHP oder Ruby (on >> Rails) entwickeln. > > Hättest alles auch mit Tcl/Tk machen können. Das heißt aber weder das > Eine, noch das Andere. Bestimmt hätte ich das, aber auch genauso komfortabel? Wenn ich mir nur einmal die dankenswerterweise im Tcl-Wiki zusammengetragene Liste [1] von Tcl-Entsprechungen für Module anschaue, die Python bereits standardmäßig mitbringt, dann... äh... es mag sein, daß die Liste nicht sehr gut gepflegt ist, aber... Ich bin sicher, für fast alles, das es in Python gibt, findet man irgendwie auch eine entsprechende Bibliothek für Tcl. Aber die muß ich dann leider erst suchen, finden, und evaluieren. Oder ich muß mir eben selbst etwas schreiben... äh, ja, leider Not Invented Here, und dann muß ich's auch noch pflegen. > Oder soll ich jetzt den Code für meinen LXI-Abfrage hier posten um > irgendwas zu belegen. Du mußt hier gar nichts belegen. > Mit den LXI-Daten bereite ich dann eine Datei für GNU-Plot auf und ruf > dann Gnuplot auf. Also ist da auch gleich Automatisierung dabei. UI ist > mit Tk. Tjaaa, wie sage ich das jetzt, ohne daß Du es gleich wieder als Kreuzzug verstehen willst? Zu den schönen Eigenschaften von Python gehört, daß ich für so etwas keine externen Programme wie gnuplot brauche. Versteh' mich nicht falsch, ich kenne und mag gnuplot, aber... wie auch Tk und Tix sieht man seinen Ergebnissen leider auch das betagte Alter des Werkzeugs an. Mir persönlich wäre das egal, aber mein Chef, nunja, der ist bei so etwas leider ein bisschen komisch. Außerdem macht Gnuplot aus den Daten leider nur eine einzelne statische Grafik. Die Python-Library Pandas dagegen kann zwar auch statische Dateien generieren, aber sie kann mir auch ein interaktives Fenster öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche genauer anschauen kann. Oder sie erzeugt mir über Bokeh eine interaktive Darstellung meiner Daten fürs Web. Vielleicht magst Du mal unter [2] in einen anderen Thread schauen, wo ich mir den Spaß gemacht habe, ein kleines Skript zur Auswertung der Lesenswert-Zähler je Autor zu schreiben; da sind unten auch ein paar mit Pandas und Bokeh erzeugte interaktive Plots zu finden. [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules [2] Beitrag "Re: Linux wird nicht wirklich akzeptiert, woran liegt das ?"
:
Bearbeitet durch Admin
schwäbisch oder sächsisch = immer noch deutsch schrieb im Beitrag #6492532: > Sheeva P. schrieb im Beitrag #6492505: >> Aber zum Glück muß ich das nicht. > > Eben. Darum braucht wir EINE Programmiersprache für alles. > > Und Python ist dafür natürlich nicht geeigent ;-) Das stimmt, wir müssen alle sofort zu Assembler wechseln. ;-)
Nick, Sheeva, bitte haltet das Persönliche aus eurer Diskussion raus, oder beendet eure Diskussion hier.
Nick M. schrieb: > Rolf M. schrieb: >> Aber auch, dass andere sich daran nicht stören und diese doch sehr >> emotionalen Reaktionen nicht nachvollziehen können. > > Kein Problem für mich. Manche mögen dicke Frauen, ich nicht. > Aber emmotional ist daran nichts. Ja, du bleibst in dem Thread sachlicher als manch anderer, wobei das hier für mich schon emotional klingt: Nick M. schrieb: > dass dieser Einrückungsvorschriftsschwachsinn einige extrem nervt (mich > z.B.). Würdest du über dicke Frauen ähnlich sprechen, nur weil du die nicht bevorzugst? > Rolf M. schrieb: >>> Was aber nicht heißt, dass die Leute gegen sauber strukturierten leserlichen >>> Quelltext sind. >> >> Das ist dann wiederum das, was ich nicht verstehe. Warum stört man sich >> daran, dass die Sprache etwas erzwingt, das man doch sowieso macht? > > **Räusper** > Schalte bitte deinen Filter aus, wenn du die Gegenseite liest. Denn das > wurde oft genug auf unterschiedliche Art und Weise erklärt. Ich hab ja schon geschrieben, dass ich über ein "das macht man nicht. Whitespace setzt man so nicht ein, basta!" hinaus nicht viel an Argumenten finden konnte. Du bist da eher die Ausnahme mit dem Argument des zur Fehlersuche temporär eingefügten Code, und ich habe ja bestätigt, dass ich das auch als störend empfinde. Aber eben bei weitem nicht so sehr, dass ich das ganze Konzept deshalb zum "Einrückungsvorschriftsschwachsinn" degradieren würde. > Nick M. schrieb: >> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC >> oder Arm. > > Kapiert? Das sowieso. Das zeigt aber auch, dass es oft nicht um harte Fakten, sondern eher um Geschmackssache geht. Aber wenn jemand hier etwas als Argument aufführt, das für mich keinen Sinn ergibt oder keine Begründung hat, frage ich trotzdem nach.
Rolf M. schrieb: > Ja, du bleibst in dem Thread sachlicher als manch anderer, wobei das > hier für mich schon emotional klingt: > > Nick M. schrieb: >> dass dieser Einrückungsvorschriftsschwachsinn einige extrem nervt (mich >> z.B.). Ist halt für mich Schwachsinn. Genauso wie die Kommentare in meinem geliebten Tcl Schwachsinn sind. Ich bezeichne das gradraus als Schwachsinn. Weil da jemand einfach nicht nachgedacht hat. Die Deutschen sind doch bei den Amis dafür bekannt, dass sie deutlich sind. Gilt das jetzt nicht mehr? Das ist Schwachsinn für mich, daher ist aber nicht die komplette Sprache Schwachsinn. Das gilt für Tcl und für Phython. Aber nicht für Spin. :-)) Ich schreib es jetzt zum gefühlt 10ten Mal: Das endet nur in einem Sprachenkrieg. Und genau so ist es. Es gibt leider paar komplett Verbohrte die Python (oder sonst eine Sprache) als Religion ansehen. Ich bin nicht mit einer Sprache verheiratet. Es gibt paar Möglichkeiten. Die Firma verlangt Python von mir, ich gewöhn mich dran. Die Firma verlangt Python von mir, dann wechsle ich die Arbeit (hab ich schon mal gemacht, nicht wg. Python) Die Firma verlangt kein Python von mir, ich machs weil es mir gefällt. Die Firma verlangt kein Python von mir, was bin ich glücklich! Niemand verlangt Python von mir, darum mach ich Rubi. Niemand verlangt Python von mir, dann trink ich lieber Bier. Niemand verlangt Python von mir, mein Nachbar kanns, darum mach ich es auch. Niemand verlangt Python von mir, darum bin ich beim Ausprobieren bei Tcl hängen geblieben. Nieman verlangt Python von mir, aber ich find es Klasse! Ich mach C, weils mir Spaß macht. Und weils mir Spaß macht, such ich mir eine Arbeit die mir Spaß macht und wo ich das verwenden kann. Genauso wie mir mal NewtonScript sehr viel Spaß gemacht hat und ich auch eine Arbeit dafür gefunden hab. München-Starnberg kann man auch mit dem Rad fahren. Und durch den Wald auch mit dem Mountainbike. Dann ist der Spaß doppelt. Bis Steve Jobs den Newton von heute auf morgen den Hahn abgedreht hat und mein Spaß ein Ende hatte. Aber ich kauf immer noch Apple-Zeugs. Leute, das ist alles in Ordnung. Und genau desshalb sind diese Glaubenskriege hier alles andere als zielführend. Was von den Mods bestätigt werden kann. ;-)) (Danke für die Geduld)
Das ist ja soweit schön und gut, allerdings: Nick M. schrieb: > Weil da jemand einfach nicht nachgedacht hat. sollte heißen: weil da jemand zu anderen Schlüssen gekommen ist, als du. Sowas passiert, das ist kein Drama – aber denen dann unterstellen, dass sie nicht nachgedacht hätten, im Umkehrschluss also sich selbst als den Maßstab von allem darzustellen – das ist, mit Verlaub, für’n Arsch.
Rolf M. schrieb: >> Nick M. schrieb: >>> Es läuft immer nur auf einen Sprachen-Krieg raus. Genauso wie Atmel PIC >>> oder Arm. >> >> Kapiert? > > Das sowieso. Das zeigt aber auch, dass es oft nicht um harte Fakten, > sondern eher um Geschmackssache geht. Äh, zum wiederholten Male: JA Ich finde xxx Schwachsinn. Lies bitte mein Posting davor bezüglich Tcl und Schwachsinn.
W.S. schrieb: > Hier geht es um das Fehlen der Blockmarkierungen und den Ersatz selbiger durch > das fehlerträchtige Maß von Einrückungen. Wie schon gesagt halte ich es für weniger fehlerträchtig, weil die Möglichkeit der Inkonsistenz zwischen Einrückung und Blockmarkierung wegfällt. Aber nun gut, da mag es andere Meinungen geben.
Jack V. schrieb: > sollte heißen: weil da jemand zu anderen Schlüssen gekommen ist, Tja, der Schöpfer der Sprache sieht das inzischen ja selbst schon nicht mehr als so genial an. Und wenn dich der Ausdruck "Schwachsinn" stört, dann nenn es halt "eine äussert ungeschickte und kurzsichtige Entscheidung die auf lange Sicht zu einem Umdenken führen wird" Ehrlich, für mich ist das halt so, denn wer Sprachen entwirft, kennt sicherlich auch andere Sprachen und deren Konzepte. Und wenn man mit einem recht einfachen und gängigen Konzept bricht, dann muss man dafür schon wirklich handfeste Argumente haben. Oder Starrköpfig sein. Oder Revanchist? Jetzt ehrlich! "Denen werde ich die Hammelbeine schon langziehen! Die werden die Einrückungen 4 Leerzeichen machen, weil ein Tab immer 4 Leerzeichen sind. Und damit die das kapieren, dürfen LZ und Tab nicht gemischt werden. Jawollllll! <harharhar>" Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere. Und darum bezeichne ich das als Schwachsinn. Anderen gefällts. Ich mag Mäuse nicht mal gebraten, die Katze frisst sie roh.
Rolf M. schrieb: > weil die > Möglichkeit der Inkonsistenz zwischen Einrückung und Blockmarkierung > wegfällt. Aber nun gut, da mag es andere Meinungen geben. Da ist auch nichts inkonsistent, das liegt nur in deinen (lobenswerten) ästhetischen Ansprüchen die dein (und erfreulicherweise auch mein) Editor gerne sklavisch auf Tastendruck umsetzt. Und jeder darf Einrücken und Zeileunumbrüche machen wie er mag und wann er mag. Juhuuuuu
Rolf M. schrieb: > Würdest du über dicke Frauen ähnlich sprechen, nur weil du die nicht > bevorzugst? Das würde der Mod dann völlig zu Recht löschen. ;-)
Bisher ausser Acht gelassene Besonderheiten, welche Python so beliebt machen: - es ist nicht C - es kommt ohne Präprozessor - es ist nicht Java - es ist nicht Perl - es ist gottlob nicht Tcl - es verunmöglicht sowas wie IOCCC - es vermeidet sowas wie MISRA - hat nicht so viele Dialekte wie K&R, ANSI, POSIX, C89, C99, ObjectiveC, C++, C#, usw. - die Transition von 2 zu 3 ist wohl nicht vollständig aber hochgradig automatisierbar dass Hilfsmittel dazu gleich mitgeliefert kommen - es hat den bewährten "pep" der offensichtlich effektiv ist (anders als ANSI oder wie das bei C/C++ heissen mag wo für alle Sonderlocken lobbyiert werden kann und letztlich alles, aber auch gar ALLES, mit rein kommt Hauptsache jedes Mitglied konnte eine Sonderlocke beitragen und keiner der alten Zöpfe wird gestrichen)
Yalu X. schrieb: >> Nur, was du sagst gilt auch für andere Scriptsprachen. >> Einschließlich der Nachteile. > > Nur dass IMHO Python mehr Vorteile und weniger Nachteile > in sich vereint als andere Programmiersprachen. Naja, leider scheint hier niemand ausreichend qualifiziert (oder motiviert), mal einen SACHLICHEN Vergleich z.B. zwischen Tcl und python vorzunehmen. Ich bin dafür nicht geeignet -- ich kenne nur Tcl. Interessieren würde es mich aber schon. >> Ich ersetzte einfach Python mit Tcl und streich den >> Satz mit der Einrückung. Ersetze ihn aber mit den >> schwachsinnigen Kommentaren in Tcl. Das ist nämlich >> gleich dumm wie die Einrückung in Python. > > Naja, zumindest die Syntax von Tcl ist im Vergleich zu > Python ja schon ziemlich primitiv und unelegant. Naja, das entbehrt nicht einer gewissen Komik, denn ein Großteil der verfügbaren Operationen und Operatoren ist 1:1 von C übernommen... (Diese Ähnlichkeit zu C halte ich übrigens für einen echten didaktischen Vorteil von Tcl.) > Sie erinnert mich stark an eine Shell-Sprache, Gut... die Substitutionsmechanismen sind ungewohnt. > mit ich ungern größere Softwareprojekte realisieren > würde, auch wenn das prinzipiell natürlich möglich > ist. Wieso? Wo ist da der Zusammenhang? Ich frage ernsthaft. Die Zuweisungen in der Form
1 | set a $b |
sind wegen der Präfixnotation und des notwendigen "$" erstmal murxig, aber das wird schnell zum Reflex. Der Hauptnachteil der eckigen Auswertungs-Klammern -- wie übrigens auch der geschweiften -- ist m.E., dass sie so beschissen auf der Tastatur zu erreichen sind. Ansonsten sehe ich in der Syntax nix, was größere Projekte verhindern würde. >> Ein Vergleich mit C, C++, Java ist nicht zielführend, >> weil das compilierte Sprachen sind. > > Warum nicht? Naja, das ist dasselbe, als wollte man eine konventionelle Dreh- oder Fräsmaschine mit einer CNC-Kiste vergleichen: CNC kann vieles, was konventionell nicht geht -- aber bei der konventionellen Maschine sehe ich viel leichter, was passiert, und kann viel leichter eingreifen. Für das Lernen und Probieren einfach besser. > Solange ein Programm tut, was es soll, [...] Nee -- interessant ist die Phase, in der das Programm noch NICHT das tut, was es soll -- vielleicht deshalb, weil ich Teile des Problems oder des Lösungsverfahrens noch nicht verstanden habe. In dieser Phase erfordern Scriptsprachen m.E. wesentlich weniger Verrenkungen.
Addendum (fast vergessen): - es darf jeder soviel einrücken wie er will solange er einrücken tut und dabei Konsistent bleibt Letztlich helfen aber "stalinistische" Tools wie pep8 einer parteidoktrinischen Gleichschaltung was Code-Style angeht, sodass SW-Engineering & -Metrik Tools auf Quellcodestufe so einfach möglich sind und gelingen dass gut und gerne auch fremde Libs mit moderatem Aufwand analysiert werden können, obendrein genausogut auch automatisch umgearbeitet sprich weiterentwickelt werden können. Bei Programmiersprachen die länger auf dieser Welt sind wurde das weniger gemacht resp. wurden damit trotz mehr Zeit weniger Fortschritte erzielt weil wohl irgendwas im Wege stand; ich mutmasse jetzt mal es sind die entweder ungünstigen Syntaxdefinitionen oder die allzu hohen/laxen Freiheitsgrade jener Syntaxen...
Nick M. schrieb: > Genauso wie die Kommentare in meinem geliebten > Tcl Schwachsinn sind. Ich bezeichne das gradraus > als Schwachsinn. Weil da jemand einfach nicht > nachgedacht hat. Ach Gott... das ist doch Kleinkram. Viel schlimmer finde ich, dass es für mehrfache Fallunterscheidungen offenbar mal eine case-Anweisung gab, die aber zu Gunsten einer C-typischen switch- Konstruktion abgeschafft wurde. So weit, so gut. Unabhängig davon gibt es natürlich eine break-Anweisung. Dumm nur, dass sich "switch" so verhält, wie man es von "case" in Pascal gewohnt ist (es gibt also keinen automatischen "fall-through"), so dass ein gewohnheitsmäßig angehängtes "break" am Ende eines Zweiges unerwartete Wirkung hat... :)
Sheeva P. schrieb: > aber sie kann mir auch ein interaktives Fenster > öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche > genauer anschauen kann. Ja toll. Und ich hab einen interaktiven Editor für harmonische Nockenwellen mit Flachstößeln in Tkl/Tk geschrieben. Wo du jeden Parameter angeben kannst und dann dazu die Erhebungskurve, die Ventilgeschwindigkeit und die Beschleunigung jeweils über °KW bei gegebener Drehzahl graphisch dargestellt wird. Der ganze Spaß wird dann als G-Code ausgegeben für die Fräsmaschine mit einer 4. Achse. Ist auch langweilig, ich weiß. Ist auch kein Argument für Tcl, ich weiß. Gilt aber genauso für Python, ich weiß. Möglicherweise weißt du nicht, dass man das "Schw*nzvergleich" nennt, ich weiß es. Sheeva P. schrieb: > [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules Hast sicherlich ganz aus Versehen das da in deinem Link übersehen: A cautionary note - the Tcl column is empty not because the functionality is unavailable, but because no one finds it worthwhile to complete the table! Also note that some of these modules make no sense for Tcl.
> Naja, leider scheint hier niemand ausreichend qualifiziert > (oder motiviert), mal einen SACHLICHEN Vergleich z.B. > zwischen Tcl und python vorzunehmen. Ich bin dafür nicht > geeignet -- ich kenne nur Tcl. Interessieren würde es > mich aber schon. MEIN ganz persönlicher Abtörner bei Tcl/Tk (das war so ca.'95) offenbarte sich als ich wiederholt /Boilerplate/scschreiben musste der Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ Einzelelement?/ Kein Element? Sowas ist mir bei Python (damals so vor 1.5 WIMRE) nie untergekommen: das abwickeln von "[]"/"[EinzelElem]"/"[Elem1, Elem2, ...]" lässt sich schön homogen mit "for el in lst"/Iterator/list-comprehnsion/list-sliceing... hinschreiben ohne dass Fallunterscheidung nötig ist. Ok, die Errinnerung an damals ist jetzt bröckelig, ich war "jung" und hatte kein Tcl-Guru in Reichweite um das gute Handwerk abzugucken. Vielleicht war(en) es auch nur bestimmte Lib-Funktionen (irgend was mit Verzeichnisse/Dateien listen) welche blöd implementiert waren... ich weiss es nicht mehr so genau ausser die Lehre welche ich mir merkte: "SOWAS will ich nicht mehr anfassen". Wie Tcl heute ist hab ich mir nicht angeguckt, ev. hat es auch Evolution genossen...
Programmiersprachentheaterintendant schrieb: > Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von > Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ > Einzelelement?/ Kein Element?
1 | foreach element $elements { |
Hast du das gesucht? ;-)
Nick M. schrieb: > Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere. Es hindert dich überhaupt keiner daran, das auch bei Python so zu handhaben. Hab ich damals™, zu Zeiten der hübschen 4:3-Monitore mit verhältnismäßig geringer Auflösung, genau so gemacht, damit’s im Editor nicht zu weit nach rechts abgehauen ist, wenn es mal etwas verschachtelter wurde. Dass es konsistent sein sollte, dürfte sich eigentlich von selbst verstehen. Zumindest würde ich ansonsten gleiches Recht für alle fordern, und in anderen Sprachen auch Klammern wild mischen dürfen:
1 | int main () [ |
2 | … |
3 | } |
OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner Klammerorgien gehasst, wenn ich damit mal zu tun hatte (und zwar noch, bevor ich Python überhaupt kannte). Ist mir aber nicht in den Sinn gekommen, es deswegen „Schwachsinn“ zu nennen und zu behaupten, ich alleine wüsste, wie man es zu machen hätte …
:
Bearbeitet durch User
Rolf M. schrieb: > Ich hab ja schon geschrieben, dass ich über ein "das macht man nicht. > Whitespace setzt man so nicht ein, basta!" hinaus nicht viel an > Argumenten finden konnte. Es gab auch einige "ich mag das einfach nicht"... ;-) > Du bist da eher die Ausnahme mit dem Argument > des zur Fehlersuche temporär eingefügten Code, und ich habe ja > bestätigt, dass ich das auch als störend empfinde. Wie müßte ich mir das mit diesem temporär eingefügten Code denn in der Praxis vorstellen? Vielleicht habt Ihr da ja andere, womöglich bessere Ideen als ich. Unterhalb der Blockebene ist mein Code üblicherweise in kleine, zusammenhängende Einheiten strukturiert. Weil das jetzt sehr abstrakt klingt, möchte ich ein kurzes Beispiel aus dem Skript geben, mit dem ich die oben verlinkte Statistik erzeuge. Da ist mir tatsächlich heute ein kleiner Fehler aufgefallen, in folgendem Code:
1 | plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() |
2 | DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', |
3 | 'Freitag', 'Samstag', 'Sonntag'] |
4 | plot_dayofweek.index = DAYS # Fehler hier! |
Es folgt noch eine Zeile, aber dies ist der Code, der den mittleren Plot in der Thread-Statistik erzeugt. Oberhalb und unterhalb des Code befindet sich jeweils eine Leerzeile, um ihn von dem Code abzusetzen, der die Plots für Stunden und Datum baut. Nun, jedenfalls warf der betreffende Code eine Exception und brach die Ausführung in der Zeile "# Fehler hier!" ab. Also habe ich meinen Code editiert:
1 | plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() |
2 | DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', |
3 | 'Freitag', 'Samstag', 'Sonntag'] |
4 | print('before error:', plot_dayofweek) # Guckstu...
|
5 | plot_dayofweek.index = DAYS # Fehler hier! |
Dabei kam heraus -- ich hatte das Skript auf diesen Thread hier angewendet -- daß dieser Thread erst seit Dienstag läuft, der Dataframe also nur vier Tage beinhaltet und daher meckert, wenn ich ihm meinen siebenstelligen Index mit allen Wochentagen zuweisen will. Jetzt sieht mein Code so aus und funktioniert wieder perfekt:
1 | plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() |
2 | DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', |
3 | 'Freitag', 'Samstag', 'Sonntag'] |
4 | days = list() |
5 | for i in plot_dayofweek.index: days.append(DAYS[i]) |
6 | plot_dayofweek.index = days |
7 | plot_dayofweek = plot_dayofweek.plot_bokeh( |
8 | kind='bar', show_figure=False, xlabel='Wochentag', |
9 | ylabel='Anzahl Beiträge', legend=None, colormap=['orange']) |
Da mein Code ansonsten keinerlei print()-Statements enthält, sondern natürlich das logging-Framework aus Pythons Standardbibliothek benutzt, wäre der Debug-Code (mit "# Wooot?" gekennzeichnet) auch schnell wiedergefunden und entfernt, ansonsten hätte ich ihn mit drei Leerzeilen abgesetzt oder mit Kommentaren gerahmt. Nebenbei hat mich das an einen anderen Punkt erinnert, der sicherlich auch zur großen Beliebtheit von Python beiträgt: die einfachen Möglichkeiten zum Debugging. Angefangen damit, daß ich Code einfach auskommentieren kann -- sowohl als einzelne Zeile mit dem auch aus anderen Sprachen bekannten Hashpound, als auch einfach als Multiline-String mit """ oder ''' an Anfang und Ende. Außerdem läßt sich so ziemlich jedes Python-Objekt in einen String wandeln und auf der Kommandozeile oder in eine Logdatei ausgeben. Wenn das noch nicht reicht, kann ich mit type() den Typ meines Objekts erfragen, mit dir() alle Symbole im aktuellen Scope ausgeben oder mit dir(obj) alle Methoden- und Eigenschaftsnamen im Scope des übergebenen Objekts. Mit vars() kann ich das die lokalen Variablen ausgeben (genau wie mit locals()), oder mit vars(obj) das interne _dict_ des übergebenen Objekts. Eine andere sehr interessante Eigenschaft sind die Docstrings -- und die manchmal sehr nützliche Möglichkeit, über die Eigenschaft _doc_ direkt aus dem Code meines Programms heraus auf die eigene Dokumentation oder die anderer Objekte zuzugreifen. Für die Docstrings gibt es noch eine andere, durchaus nützliche Verwendung: die Doctests. Damit kann ich für simple Klassen und Funktionen ganz einfach eine Art Unittest erstellen: ich lade das Teil in eine interaktive Python-Shell, lade meine Funktionen und Klassen, führe sie aus und speichere das in einem Docstring. Dazu ein kleines Beispiel:
1 | #!/usr/bin/env python
|
2 | """
|
3 | just some simple demo
|
4 | |
5 | >>> from b import * |
6 | >>> d = Dings(90) |
7 | >>> what('d', d) |
8 | +++ inspecting "d" begin |
9 | docstring: just some Dings class |
10 | type(): <class 'b.Dings'> |
11 | dir(): ['__class__', '__delattr__', '__dict__', '__dir__' |
12 | vars(): {'a': 10, 'b': 20, 'c': 90} |
13 | --- inspecting "d" |
14 | >>>
|
15 | """
|
16 | |
17 | |
18 | def what(name, obj, linelen=50, indent=4):
|
19 | """inspects an named object obj""" |
20 | print('+++ inspecting "{}" begin'.format(name)) |
21 | print(' '*indent + 'docstring:', obj.__doc__) |
22 | print(' '*indent + 'type(): {}'.format(type(obj))) |
23 | print(' '*indent + 'dir():', str(dir(obj))[:linelen]) |
24 | try: print(' '*indent + 'vars():', str(vars(obj))[:linelen]) |
25 | except: pass
|
26 | print('--- inspecting "{}"'.format(name)) |
27 | |
28 | |
29 | class Dings(object):
|
30 | """just some Dings class""" |
31 | def __init__(self, c):
|
32 | self.a = 10
|
33 | self.b = 20
|
34 | self.c = c
|
35 | |
36 |
|
37 | if __name__ == '__main__': |
38 | d = Dings(30)
|
39 | what('d', d) |
Wenn ich das mit "python -m doctest -v b.by" ausführe, ist die Ausgabe wie folgt:
1 | Trying: |
2 | from b import * |
3 | Expecting nothing |
4 | ok |
5 | Trying: |
6 | d = Dings(90) |
7 | Expecting nothing |
8 | ok |
9 | Trying: |
10 | what('d', d)
|
11 | Expecting: |
12 | +++ inspecting "d" begin |
13 | docstring: just some Dings class |
14 | type(): <class 'b.Dings'> |
15 | dir(): ['__class__', '__delattr__', '__dict__', '__dir__' |
16 | vars(): {'a': 10, 'b': 20, 'c': 90}
|
17 | --- inspecting "d" |
18 | ok |
19 | 3 items had no tests: |
20 | b.Dings |
21 | b.Dings.__init__ |
22 | b.what |
23 | 1 items passed all tests: |
24 | 3 tests in b |
25 | 3 tests in 4 items. |
26 | 3 passed and 0 failed. |
27 | Test passed. |
Diese "Unittests" sind zwar sehr einfach, und für umfangreicheren Code würde ich natürlich ein entsprechendes Framework wie das im Standardumfang von Python befindliche unittest, oder auch etwas externes wie PyTest oder Testify nehmen. Jedoch... für einfache Anwendungsfälle ist doctest schon sehr brauchbar, nicht zuletzt auch, weil der Code in den Kommentaren gleichzeitig auch beispielhaft dokumentiert, wie die einzelnen Objekte genau benutzt werden.
Nick M. schrieb: > Programmiersprachentheaterintendant schrieb: >> Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von >> Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ >> Einzelelement?/ Kein Element? > >
1 | > foreach element $elements { |
2 | >
|
> > Hast du das gesucht? ;-) Ich verstehe zwar dein ";-)" und auch wenn meine Errinnerungen nicht mehr so präzise sind, bin ich doch zuversichtlich dass ich das gefunden hatte. Meine Beschreibung sagt aber dass die Fallunterscheidung nötig war BEVOR das zur anwendung kommen kann. Ich versuche zu rekonstruieren: schreib in deinem Codeabschnitt an Stelle von "$elements" einen Funktionsaufruf hin - geht das dann immernoch? Egal ob die Funktion eine mehrelementige Liste oder ein Einzelelement oder NOPE zurückgibt?
Nick M. schrieb: > Oder Revanchist? Jetzt ehrlich! > "Denen werde ich die Hammelbeine schon langziehen! Die werden die > Einrückungen 4 Leerzeichen machen, weil ein Tab immer 4 Leerzeichen > sind. Und damit die das kapieren, dürfen LZ und Tab nicht gemischt > werden. Jawollllll! <harharhar>" > > Bei mir sind Tabs immer schon 2 LZ. Seit ich programmiere. Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt. Es muß nur konsistent sein. Ich hab früher übrigens auch zwei Leerzeichen benutzt, bis ich irgendwann zu faul wurde, den Editor umzukonfigurieren und meine Mitarbeiter und Kollegen damit zu stressen.
Jack V. schrieb: > Zumindest würde ich ansonsten gleiches > Recht für alle fordern, und in anderen Sprachen auch Klammern wild > mischen dürfen: Huch! Hab ich das gefordert? Dann muss ich mich entschuldigen! Das wäre ja Schwachsinn[tm]. Jack V. schrieb: > OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner > Klammerorgien gehasst, OK, ich hab vorher ObjC gelernt, da gewöhnt man sich an eckige Klammern gaaaanz schnell. Und dass bei jedem Funktionsaufruf der parameter auch mit Namen genannt werden muss (wie bei Verilog wenn man die Reihenfolge ändert). Und irgendwie muss man da immer von innen nach aussen lesen, wobei innen eher rechts steht. Ist halt so, es war meine Lieblingssprache bis jetzt. Aber sublime macht aus einem "proc<tab> ein: proc name {args} \ { } Darum liebe ich Orgien. ;-) Aber zugegeben, mit diesen eckigen und geschweiften Klammern oder die "" und was die machen oder nicht, das ist nicht ganz so einfach. Aber das ist halt Syntax die festlegt wann Ausdrücke berechnet werden. Und das find ich verdammt cool. Aber eigentlich geht es um Python, nicht dass noch einer vom Glauben abfällt. ;-)
Egon D. schrieb: > Yalu X. schrieb: >> Nur dass IMHO Python mehr Vorteile und weniger Nachteile >> in sich vereint als andere Programmiersprachen. > > Naja, leider scheint hier niemand ausreichend qualifiziert > (oder motiviert), mal einen SACHLICHEN Vergleich z.B. > zwischen Tcl und python vorzunehmen. Ich bin dafür nicht > geeignet -- ich kenne nur Tcl. Interessieren würde es > mich aber schon. Vielleicht ließe sich das ja als eine Art "Gemeinschaftsarbeit" in einem eigenen Thread machen? Immerhin gibt es hier in diesem Thread schon doppelt so viele Tcl-Freunde, als mir bisher je persönlich begegnet sind. > Naja, das entbehrt nicht einer gewissen Komik, denn ein > Großteil der verfügbaren Operationen und Operatoren ist > 1:1 von C übernommen... > > (Diese Ähnlichkeit zu C halte ich übrigens für einen > echten didaktischen Vorteil von Tcl.) Naja, die Syntax von C als hochentwickelt oder gar eleganz zu bezeichnen, erscheint mir allerdings ziemlich... mutig. > Die Zuweisungen in der Form >
1 | > set a $b |
2 | > |
> sind wegen der Präfixnotation und des notwendigen "$" > erstmal murxig, aber das wird schnell zum Reflex. Immerhin wurde meines Wissens auf echte polnische Notation verzichtet -- und, vor allem, auf Klammern! >> Solange ein Programm tut, was es soll, [...] > > Nee -- interessant ist die Phase, in der das Programm noch > NICHT das tut, was es soll -- vielleicht deshalb, weil ich > Teile des Problems oder des Lösungsverfahrens noch nicht > verstanden habe. In dieser Phase erfordern Scriptsprachen > m.E. wesentlich weniger Verrenkungen. Vor allem sind sie meistens kompakter, man muß sich bei der Fehlersuche also durch wesentlich weniger Code fräsen. Und Skriptsprachen bieten, wenngleich in ziemlich unterschiedlichem Ausmaß, oft viel bessere Möglichkeiten zur Introspektion.
Jack V. schrieb: > OT: weil du TCL ins Spiel gebracht hast: ich hab das > wegen seiner Klammerorgien gehasst, Das ist legitim (auch wenn es mir nicht so geht). > Ist mir aber nicht in den Sinn gekommen, es deswegen > „Schwachsinn“ zu nennen [...] Kannst Du ja bei Bedarf noch nachholen... :) > und zu behaupten, ich alleine wüsste, wie man es zu > machen hätte … Nee, umgekehrt: Es geht nur darum, wie man es garantiert NICHT machen soll. Siehe mein Beispiel mit "switch": Tcl ahmt in vielen Dingen C nach (und das ist auch gut so), gerade was die Steuerstruktur betrifft. Wie man da auf die Idee kommen kann, eine Steueranweisung zu schaffen, die GENAUSO aussieht wie die Entsprechung in C, sich aber ANDERS verhält -- das wird mir ewig ein Rätsel bleiben. Das ist doch geradezu eine Einladung für idiotische Irrtümer!
Sheeva P. schrieb: > Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die > Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt. Nur nicht Tabs und LZ mischen, das hab ich schon verstanden. Ist ja auch einleuchtend, denn so darf jeder das machen was einer festlegt. Wobei es jeder so machen kann, wie er mag, solang sich die Anderen daran halten. 8-/
Nick M. schrieb: > Sheeva P. schrieb: >> aber sie kann mir auch ein interaktives Fenster >> öffnen, in das ich zum Beispiel hineinzoomen und bestimmte Bereiche >> genauer anschauen kann. > > Ja toll. Und ich hab einen interaktiven Editor für harmonische > Nockenwellen mit Flachstößeln in Tkl/Tk geschrieben. Schick, aber Du hattest ein Beispiel genannt und ich erklärt, daß es in Python für dieses Beispiel deutlich bessere (und hübschere) Möglichkeiten gibt, und zwar ohne dazu auf externe Software zugreifen zu müssen. > Möglicherweise weißt du nicht, dass man das "Schw*nzvergleich" nennt, > ich weiß es. Ach... Du kannst es einfach nicht lassen, nein? > Sheeva P. schrieb: >> [1] https://wiki.tcl-lang.org/page/Tcl+Equivalents+of+Python+Modules > > Hast sicherlich ganz aus Versehen das da in deinem Link übersehen: Nein. Im Gegenteil hatte ich sogar ausdrücklich dazu geschrieben, daß diese Liste womöglich unvollständig sein könnte.
Nick M. schrieb: > Programmiersprachentheaterintendant schrieb: >> Fallunterscheidungen/Fehlerbehandlung bei Entgegennahme von >> Funtionsrückgaben abwickeln musste: Liste (mit mehreren Elemente)?/ >> Einzelelement?/ Kein Element? > >
1 | > foreach element $elements { |
2 | >
|
> > Hast du das gesucht? ;-) Ich glaube, er meint das, was in Python als List Comprehension bezeichnet wird. Die beiden folgenden Codeteile tun (im Prinzip) dasselbe:
1 | result = list() |
2 | for elem in liste: |
3 | result.append(machwas(elem)) |
und
1 | result = [machwas(elem) for elem in liste] |
Das ist hier nur ein bisschen syntaktisches Zückerchen, inspiriert von Haskell. Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp tuple), quasi einer unveränderlichen Liste, weil die keine append()-Methode haben (unveränderlich halt), so daß das erste Beispiel die Ergebnisse von machwas() dann nämlich erst in einer Liste sammeln und diese dann in ein Tupel umwandeln müßte.
Jack V. schrieb: > OT: weil du TCL ins Spiel gebracht hast: ich hab das wegen seiner > Klammerorgien gehasst, wenn ich damit mal zu tun hatte (und zwar noch, > bevor ich Python überhaupt kannte). Äh, Du meinst jetzt aber nicht Lisp, oder? ;-)
Sheeva P. schrieb: > Äh, Du meinst jetzt aber nicht Lisp, oder? Nein. Jede andere Sprache, die ich zu der Zeit kannte, kam mit erheblich weniger Klammern aus. Abgesehen davon: „God wrote in Lisp“ – ich selbst habe es nicht gelernt/genutzt, aber wenn Leute Lieder drüber schreiben, kann es ja auch nicht ganz verkehrt sein, oder?
:
Bearbeitet durch User
Nick M. schrieb: > Aber sublime macht aus einem "proc<tab> ein: > proc name {args} \ > { > > } Äh... ist der Backslash da wirklich notwendig? 8-O
"Die Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das jetzt seit 5 Jahren veröffentlicht ist." perl6 wird wohl viel eher als eigene, unabhängige Sprache gesehen. Und zum Teil auch als eine Totgeburt.
Egon D. schrieb: > Siehe mein Beispiel mit "switch": Tcl ahmt in vielen > Dingen C nach Das ist so wie mit Französisch, Italienisch und Spanisch. Gleicher Sprachstamm. Wer Französich kann, tut sich mit Italienisch leicht oder versteht es zumindest ansatzweise. Manche Französischen Wörter spricht man einfach italienisch aus und das passt dann. So wie Italiener sich leicht tun wenn die Spanier endlich mal langsam sprechen. Aber es gibt keinen Anspruch darauf, dass Fränzösich wie Italienisch und Tcl wie C verhalten muss. Und dass das alles von Latein abstammt, hab ich als Neusprachler unterschlagen. Alle Sprachen sind nur ein Ausdrucksmittel. Das gilt für C und für Python und für Russisch (Äquivalent zu APL). In der einen Sprache lässt sich etwas kompakter oder einfacher oder umständlicher oder klangvoller ausdrücken wie in der Anderen. Das Französisch die Sprache der Liebe ist ist genauso Quatsch wie dass Deutsche Spaß verstehen und Italiener bei Deutsch immer nur Karrrtoffel hören. Dafür kullern sich die Italiener warum die Bayern immer Grüß Gott sagen. Die verstehen nämlich cruscotto, was Armaturenbrett bedeutet. So wie halt die Zahlen in Französich ziemlicher Schwachsinn sind. Wer 92 wie "Vier (mal) zwanzig zwölf" ausspricht, kann nicht ganz dicht sein. Aber Käse können sie!
Das gilt aber nur so lange, wie man sich im gleichen Paradigma bewegt. https://de.wikipedia.org/wiki/Programmierparadigma Der Schritt von Perl zu Python ist kleiner als der zu Prolog.
:
Bearbeitet durch User
Sheeva P. schrieb: > Äh... ist der Backslash da wirklich notwendig? 8-O Ja. :-)) Ich schreib es aber anders, nämlich so wie eigentlich alle Anderen: { } { Dann braucht man den Backslash nicht. Und ja, auch das ist Unsinn. Aber ich kann es zugeben! Das macht mir mein Leben einfacher.
Nick M. schrieb: > Sheeva P. schrieb: >> Jetzt ehrlich: Python ist das vollkommen gleichgültig, ob Du für die >> Indentation nun ein, zwei, vier oder drölf Leerzeichen benutzt. > > Nur nicht Tabs und LZ mischen, das hab ich schon verstanden. > Ist ja auch einleuchtend, denn so darf jeder das machen was einer > festlegt. > Wobei es jeder so machen kann, wie er mag, solang sich die Anderen daran > halten. > 8-/ Nein, sogar das ist dem Parser vollkommen wumpe -- jedenfalls, solange es nicht in derselben Datei passiert. Wenn Du Deinen Code also mit einer Indentierung von zwei Leerzeichen schreibst, kannst Du jederzeit Code laden, der sich an PEP8 hält, also vier Leerzeichen dafür benutzt. Da ist Python -- wie in vielen anderen Dingen -- ziemlich frei und setzt mehr auf Konventionen als auf Zwänge.
Irgendwann ist vielleicht mal der Punkt erreicht wo jemand sagt "He, die vorhandenen Sprachen sind jetzt langsam mal gut genug, jetzt können wir uns endlich aus Programmieren konzentrieren statt dauernd vermeintlich bahnbrechenden, inkompatiblen Neuerungen hinterherzuwarten" :) ... Wenn man auf konsequent andere Syntax steht: Forth bzw Postscript (letztere Sprache ist sogar tatsächlich verflixt elegant wenn man sich Beispiele ansieht die nicht von einem Druckertreiber zusammengestampft wurden :) )
Sheeva P. schrieb: > Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp > tuple), quasi einer unveränderlichen Liste, weil die keine > append()-Methode haben (unveränderlich halt), Konstante gibts nicht in Tcl. Man kann aber ein event (eine Funktion) drauf setzen wenn eine Variable, egal von wem, geändert wird. Eine n-Tupel im mathematischen Sinne wäre eine Liste. Daraus könnte man eine Liste von Listen machen oder flach in eine Liste schreiben. Das foreach kann dann bei letzteren wieder was schönes machen: foreach tuple1 tuple2 tuple2 in $listOfFlatTuples { ... Die andere Schreibweise wäre ein 'lmap' über eine Liste.
Sheeva P. schrieb: > Nein, sogar das ist dem Parser vollkommen wumpe -- jedenfalls, solange > es nicht in derselben Datei passiert. Also doch nicht wumpe. Ausser "wumpe" bedeutet für dich "zwingend erforderlich".
Andy D. schrieb: > "Die Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das > jetzt > seit 5 Jahren veröffentlicht ist." > > perl6 wird wohl viel eher als eigene, unabhängige Sprache gesehen. Und > zum Teil auch als eine Totgeburt. Ja, sie haben Perl6 jetzt in Rake umbenannt. Wobei eine der ultimativen Stärken von Perl das CPAN war, wo es -- ähnlich wie heute in Python -- Bibliotheken für nahezu alles gegeben hat. Keine Ahnung, wie das weitergehen soll... :-( Mir tut die heutige Situation von Perl in der Seele weh, schließlich hat es mich über zehn Jahre begleitet und war mir immer ein guter, treuer Freund. Heute benutze ich es nurmehr als Filter in der Shell:
1 | cat 507607.html | perl -pe 's/Andy D./andi d./g' |
an Stellen, wo andere zu sed(1) oder awk(1) greifen... wirklich schade. Aber gleichzeitig bin ich auch dankbar: Perl hat mich viel über Skriptsprachen und ihre Ausführungsmodelle, über Perl-Compatible Regular Expressions, und über krude Objektorientierung (bless...) gelehrt. Lustige Anekdote: vor vielen Jahren -- als Perl6 gerade im Gespräch und ich noch nicht zu Python gewechselt war, hat mir ein Lektor des Rheinwerk-Verlags angeboten, ein Buch über Perl6 zu schreiben... Heute sind wir vermutlich beide froh, daß ich damals abgelehnt habe. Und zu den besten Programmierbüchern, die ich je gelesen habe, gehört immer noch "Objektorientiert Programmieren mit Perl" von Damian Conway.
Nick M. schrieb: > Sheeva P. schrieb: >> Äh... ist der Backslash da wirklich notwendig? 8-O > > Ja. :-)) Oh, interessant. > Ich schreib es aber anders, nämlich so wie eigentlich alle Anderen: > { } { > Dann braucht man den Backslash nicht. Und ja, auch das ist Unsinn. > Aber ich kann es zugeben! Das macht mir mein Leben einfacher. Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine Rolle, oder verstehe ich da gerade etwas falsch? Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe. Auch in C, C++, JavaScript, Perl, PHP, Java, Scala, Kotlin -- und ein paar anderen Sprachen, die ich glücklich- und erfreulicherweise schon vergessen habe -- und sogar in LaTeX, CSS, HTML, XML, JSON, SVG, SQL, und wie das olle Gerümpel auch heißen mag, habe ich immer penibelst auf eine saubere Einrückung geachtet. Passiert mir ja ohne das schon oft genug, daß ich beim Lesen von Code in einer von zwei Situationen bin: entweder denke ich "Alter, was für ein Genie, so gut würde ich auch programmieren können" oder "Meine Güte, was für ein Scheiß, welcher Idiot hat das verbrochen". Am Ende stellt sich dann (für meinen Geschmack zu oft) heraus: ist beides von mir. Zum Glück ist die erste Situation noch häufiger -- und wenn sie das nicht mehr ist, dann suche ich mir was Neues. Blumenpflücken soll ja sehr entspannt sein.
Nick M. schrieb: > Egon D. schrieb: >> Siehe mein Beispiel mit "switch": Tcl ahmt in >> vielen Dingen C nach > > Das ist so wie mit Französisch, Italienisch und > Spanisch. Gleicher Sprachstamm. Fast -- aber nicht ganz dasselbe: Natürliche Sprachen werden letztlich beim Sprechen durch die Sprechenden geformt -- formale Sprachen haben einen Schöpfer, und der kann halt auch mal Fehlentscheidungen treffen :) > Aber es gibt keinen Anspruch darauf, dass Fränzösich > wie Italienisch und Tcl wie C verhalten muss. Wer redet von "Anspruch"? Du musst Tcl übrigens mir gegenüber nicht verteidigen :) Lange Zeit ist mir die Verwandtschaft zwischen Tcl und C gar nicht aufgefallen; ich kann (noch) kein C. Als ich mit Lernen anfing, stellte ich dann freudig erregt fest, dass ich einen Großteil der Steuerstruktur und einen Teil der Operatoren von C schon kenne. Nur die Ausnahme mit "switch" und "break" stach halt ins Auge; das hätte m.E. nicht sein müssen. > Alle Sprachen sind nur ein Ausdrucksmittel. Das gilt > für C und für Python und für Russisch (Äquivalent zu > APL). In der einen Sprache lässt sich etwas kompakter > oder einfacher oder umständlicher oder klangvoller > ausdrücken wie in der Anderen. Ja sicher -- aber (danke für die Vorlage) hier wurde ein "falscher Freund" geschaffen, der nicht hätte sein müssen. Mehr habe ich gar nicht gesagt.
Sheeva P. schrieb: > Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine > Rolle, oder verstehe ich da gerade etwas falsch? Ja, halbwegs schlecht geschauspielert. Es geht um das '\n' das durch das '\\' aufgehoben wird. Du kannst also beliebig viele LZ oder <tab> einfügen, was ja auch Whitespaces sind. Was aber nicht bedeutet, dass ich das sinnvoll finde. Sheeva P. schrieb: > Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht > für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung > dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe. Deine Hartnäckigkeit ist erschreckend! Wer hat hier jemals abgestritten, dass sauberes Formatieren einfach zum Handwerkzeug gehört? Oh, und das muss natürlich ein Monospaced Font sein, sonst klappt das nicht. Aber das ist ja loooogisch. **Pffff** Wie viele Compiler // Interpreter // Parser hast du schon geschrieben? Ich vermute das nähert sich extrem gegen Null. Sheeva P. schrieb: > und wie das olle Gerümpel auch heißen mag, habe ich immer penibelst auf > eine saubere Einrückung geachtet. Ah, wenn ich einen Dump einer XML-Nachricht mach, dann ist der eingerückt. Wenn ich die zum Server schick ist das ein schweinelanger Einzeiler. Weil sonst das Gejammer losgeht dass so viele unnötige Daten übertragen werden **heul**. Der Inhalt ist aber identisch. Genauso kann ich das auch empfangen, unnötige Whitespaces wirden als allererstes beim Parsen wegeworfen. OK, ist das jetzt sauber:
1 | void doit(int p1, int p2, // undsoweiterbiszumzeilenende |
2 | int p10, int p11) { |
Oder doch lieber so:
1 | void doit(int p1, int p2, // undsoweiterbiszumzeilenende |
2 | int p10, int p11) { |
Oder machen wir es lieber wie in Verlilog
1 | void doit(int p1, |
2 | int p2, |
3 | // undsoweiter
|
4 | int p10, |
5 | int p11) { |
oder so sieht man es auch:
1 | void doit(int p1, |
2 | int p2, |
3 | // undsoweiter
|
4 | int p10, |
5 | int p11) { |
Weißt du, wo ich <tab> und wo ich LZ getippt hab? Ist doch egal, sieht man ja nicht. Nur weil du es als sauber betrachtes, müssen das nicht Alle so sehen. Dem C-Compiler sind alle Varianten wurscht. Er überlässt meine persönlichen Vorstellungen weitestgehend mir. Versuch endlich mal Darstellung und Inhalt auseinander zu halten. Das sind zwei Dinger.
Egon D. schrieb: > Ja sicher -- aber (danke für die Vorlage) hier wurde ein > "falscher Freund" geschaffen, der nicht hätte sein müssen. Meinst du den Russen? Kennst du APL? https://de.wikipedia.org/wiki/APL_(Programmiersprache)
Andy D. schrieb: > Irgendwann ist vielleicht mal der Punkt erreicht wo jemand sagt "He, die > vorhandenen Sprachen sind jetzt langsam mal gut genug, jetzt können wir > uns endlich aus Programmieren konzentrieren statt dauernd vermeintlich > bahnbrechenden, inkompatiblen Neuerungen hinterherzuwarten" :) Naja, im Prinzip ist das ja zumindest bei den Skriptsprachen schon der Fall. Alle heute weit verbreiteten Sprachen stammen im Wesentlichen aus derselben Epoche, die allerdings damals noch geprägt war von Single-Core-CPUs. Heute ist die Situation allerdings anders, die meisten Prozessoren haben mehrere Rechenkerne und viele sogar mehrere Threads pro Rechenkern (Hyperthreading). Das verändert die Bedingungen, für die Skriptsprachen entwickelt werden. Python und Ruby zum Beispiel leiden an etwas, das sich "Global Interpreter Lock" nennt. Das ist wirklich nervig, weil es ein wirkliches Multithreading effektiv verhindert. CPython hat deswegen ein Modul namens multiprocessing mit im Prinzip derselben Syntax wie das multithreading-Modul, was die Sache wieder ein bisschen erträglicher macht. Lustigerweise kennen Jython und IronPython, die auf Java und C# basieren, sowas wie ein GIL nicht. Aber die haben ihre eigene Garbage Collection -- die zumindest unter Java mit dem ZeroGC etwas erträglicher geworden ist und vorher gerne unter Memory Leaks und anderen Nickeligkeiten gelitten hat. Insofern, kurz gesagt: die Hardware entwickelt sich weiter, und damit müßten das auch die Programmiersprachen tun. Aber die verbreitetsten Skriptsprachen sind noch aus einer Zeit der einzelnen Singlecore-CPUs. Mein damaliger Arbeitgeber Sun hat Java entwickelt, und da wir damals schon Maschinen mit mehreren Kernen hatten, ist das einer der wenigen Aspekte, in denen Java wirklich stark ist. Insofern, um Deine Frage zu beantworten: nein, die heutigen Sprachen sind noch lange nicht gut genug und werden es auch morgen nicht sein. Übermorgen vielleicht, ja. Es wird sich zeigen, welche überleben und welche nicht. Und dann lernen wir halt eine neue Sprache. Na und? Das tut nur den One-Trick-Ponies weh... und auch die werden dann entweder Blümchenpflücker oder Rentner. PS: Bevor ich hier wieder wegen der One-Trick-Ponies angekackt werde... Es gibt einige Softwareentwickler, die genau eine Sprache können und sich mit Händen und Füßen dagegen wehren, eine neue zu lernen. Aus meiner persönlichen Erfahrung liegt das oft daran, daß man mit der ersten Programmiersprache ja nicht nur die Sprache, sondern auch das Programmieren erlernen muß. Letzteres ist der wesentlich härtere Teil, und... für manche Menschen ist das so eine böse Erfahrung, daß sie sich die nicht noch einmal antun wollen. :-(
Nick M. schrieb: > Sheeva P. schrieb: >> Spannender wird die Sache im Zusammenhang mit Tupeln (Datentyp >> tuple), quasi einer unveränderlichen Liste, weil die keine >> append()-Methode haben (unveränderlich halt), > > Konstante gibts nicht in Tcl. Man kann aber ein event (eine Funktion) > drauf setzen wenn eine Variable, egal von wem, geändert wird. Ja, nein, vielleicht... Python hat zwei Datentypen für Listen, nämlich die Liste (list) und das Tupel (tuple). Ein Tupel als solches ist unveränderlich, aber ich kann einer Variablen, die ein Tupel hält, selbstverständlich immer ein anderes Tupel zuweisen. Denn Python ist dynamisch typisiert, bindet die Datentypen also an den Wert einer Variablen statt wie C, , C++ und Java, ans Symbol. > Eine n-Tupel im mathematischen Sinne wäre eine Liste. Daraus könnte man > eine Liste von Listen machen oder flach in eine Liste schreiben. Das > foreach kann dann bei letzteren wieder was schönes machen: > > foreach tuple1 tuple2 tuple2 in $listOfFlatTuples { Mehrfachzuweisung, nice. Python, anyone? Aber (unter anderem) deswegen gibt es in Python einen spezialisierten Iterable-Typ wie das Tupel. Damit Du sicher sein kannst, daß Dein Listelement nur genau drei Werte enthält... ;-)
Egon D. schrieb: > Habe ich das jetzt richtig verstanden: [...] > das in Python die Blockstruktur gar nicht AUSSCHLIESSLICH durch > Einrückungen definiert wird, sondern durch DOPPELPUNKTE > IN KOMBINATION MIT EINRÜCKUNG? > > Ist das korrekt bei mir angekommen? Und: Egon D. schrieb: > ich kann (noch) kein C Du sagst selbst, Du kennst weder Python noch C. Ich stelle es mir sehr schwierig vor, mit so wenig Wissen und ohne Erfahrung an dieser Diskussion hier aktiv teilzunehmen.
Nick M. schrieb: > Oh, und das muss natürlich ein Monospaced Font sein, sonst klappt das > nicht. Nein, das ist falsch, da auch in einer proportionalen Schrift das Leerzeichen eine fixe Breite besitzt.
Beitrag #6493125 wurde von einem Moderator gelöscht.
Irgendwer schrieb: > Egon D. schrieb: >> ich kann (noch) kein C > > Du sagst selbst, Du kennst weder Python noch C. > > Ich stelle es mir sehr schwierig vor, mit so wenig > Wissen und ohne Erfahrung an dieser Diskussion hier > aktiv teilzunehmen. Echt jetzt?! Falls mir mal SEHR langweilig sein sollte und ich Lust habe, mich provozieren zu lassen, sage ich bescheid. Im Moment ist das noch nicht der Fall.
Nick M. schrieb: > Egon D. schrieb: >> Ja sicher -- aber (danke für die Vorlage) hier wurde ein >> "falscher Freund" geschaffen, der nicht hätte sein müssen. > > Meinst du den Russen? Nein. Ich meine immer noch die switch-Anweisung in Tcl bzw. in C. Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend, dass Du nicht entweder zugeben kannst, dass ich Recht habe, oder mir nachweist, dass ich mit meinen Aussagen Unrecht habe. Das ist m.E. unter Deinem Niveau -- aber das ist letztlich Deine Sache. > Kennst du APL? Nein -- aber eins glaube ich ohne jeden Nachweis: Schlimmer geht es immer.
Nick M. schrieb: > Sheeva P. schrieb: >> Alles gut, aber... äh... dann spielt Whitespace ja auch in Tcl eine >> Rolle, oder verstehe ich da gerade etwas falsch? > > Ja, halbwegs schlecht geschauspielert. Es geht um das '\n' das durch das > '\\' aufgehoben wird. Du maskierst ein Newline. Wow. > Sheeva P. schrieb: >> Wie auch immer: ich halte die Sache mit der Einrückung in Python nicht >> für Unsinn, sondern... im Prinzip eher für eine Art Konsolidierung >> dessen, was der Interpreter oder Compiuler sieht und dem, was ich sehe. > > Deine Hartnäckigkeit ist erschreckend! Wer hat hier jemals abgestritten, > dass sauberes Formatieren einfach zum Handwerkzeug gehört? Du bezeichnest eine von Pythons Eigenschaften als "Schwachsinn", weil es nunmal diese Eigenschaft hat. Ich hingegen habe praktische Erfahrung mit Python und weiß deswegen, daß das kein "Schwachsinn" ist. Wer von uns beiden kann jetzt wohl die qualifiziertere Aussage darüber treffen? > Wie viele Compiler // Interpreter // Parser hast du schon geschrieben? Keine Ahnung. Zehn, Zwanzig, Tausend? Wayne? > Ich vermute das nähert sich extrem gegen Null. Ach, vermute Du mal. ;-) > Weißt du, wo ich <tab> und wo ich LZ getippt hab? Ist doch egal, sieht > man ja nicht. Ja... und? Was ist Dein Punkt? > Nur weil du es als sauber betrachtes, müssen das nicht Alle so sehen. Schon wieder so eine Unterstellung. Kannst Du das wirklich nicht besser? Ja, ich halte das für eine gute Idee, weil es die Sicht des Übersetzers mit der des Entwicklers zusammenbringt. Das darfst Du aber gern anders sehen.
:
Bearbeitet durch User
Irgendwer schrieb: > Nein, das ist falsch, da auch in einer proportionalen Schrift das > Leerzeichen eine fixe Breite besitzt. Es würde mich nicht wundern, wenn hier jemand seinen Code im Blocksatz formatiert.
Jemand schrieb: > Irgendwer schrieb: >> Nein, das ist falsch, da auch in einer proportionalen >> Schrift das Leerzeichen eine fixe Breite besitzt. > > Es würde mich nicht wundern, wenn hier jemand seinen > Code im Blocksatz formatiert. Dann aber auch als Knittelvers.
Beitrag #6493258 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Nein. Ich meine immer noch die switch-Anweisung in Tcl bzw. > in C. Ah, OK. > Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend, > dass Du nicht entweder zugeben kannst, dass ich Recht habe, > oder mir nachweist, dass ich mit meinen Aussagen Unrecht > habe. Wegen dem switch / case? Ja, hab ich doch schon beantwortet. Nur weil deinem Empfinden nach Sprachen ähnlich sind, kannst du doch nicht fordern, dass die das switch und case gleich verwenden. Ist halt so. Soll ich mich darüber aufregen? Wenn ich mich über den Unterschied aufregen würde, werde die Konsequenz, dass es nur eine einzige Programmiersprache gäbe. Da wäre ich dagegen. Und zu deiner Beruhigung: Du hast weder Recht noch Unrecht. Dir gefällt es nicht. Und das ist absolut OK. Ich find auch nicht, dass C ähnlich zu Tkl ist. Da ist Python deutlich näher dran.
Jemand schrieb: >> Nein, das ist falsch, da auch in einer proportionalen Schrift das >> Leerzeichen eine fixe Breite besitzt. > > Es würde mich nicht wundern, wenn hier jemand seinen Code im Blocksatz > formatiert. D. Knuth, Literate Programming Muss man gelesen haben.
Sheeva P. schrieb: > also nur vier Tage beinhaltet und daher meckert, wenn ich ihm meinen > siebenstelligen Index mit allen Wochentagen zuweisen will. Jetzt sieht > mein Code so aus und funktioniert wieder perfekt: > plot_dayofweek = df.groupby(df.time.dt.dayofweek).time.count() > DAYS = ['Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', > 'Freitag', 'Samstag', 'Sonntag'] > days = list() > for i in plot_dayofweek.index: days.append(DAYS[i]) > plot_dayofweek.index = days > plot_dayofweek = plot_dayofweek.plot_bokeh( > kind='bar', show_figure=False, xlabel='Wochentag', > ylabel='Anzahl Beiträge', legend=None, colormap=['orange']) > > Da mein Code ansonsten keinerlei print()-Statements enthält, sondern Urgs, das wäre nicht mein Python Stil :-)
1 | ... |
2 | DAYS = 'Montag Dienstag Mittwoch Donnerstag Freitag Samstag Sonntag'.split() |
3 | plot_dayofweek.index = tuple( DAYS[i] for i in plot_dayofweek.index ) |
4 | ... |
Sheeva P. schrieb: > Wer diesen Thread > vorurteilsfrei und objektiv liest, erkennt schnell: von denen, die > Python tatsächlich benutzen, also: deren Urteil in ihrer eigenen > praktischen Erfahrung fundiert ist, hat kein einziger ein Problem mit > dieser Spracheigenschaft. Dann lies nochmal objektiv, denn diese Aussage ist definitiv falsch. Ich nutze Python weil es, nach Abwägen aller Vor- und Nachteile, für mich insgesamt das beste Gesamtpaket mitbringt. Das Whitespace-"Feature" zähle ich aber als großen Nachteil. Klar, ein Problem stellt es jetzt nicht dar. Es nervt einfach nur.
Angehängte Dateien:
-
pandas_demo.jpg
240 KB
@All from this thread, ich lass mal auch was vom Stapel ;-) Nachdem ich mit Python3 erst vor zwei Jahren angefangen habe, davor war Perl5 und bash mein Skripting Favorit bin ich nun aber von Python3 zumindest recht angetan. Die Problematik und die Diskussion über die Tab/Space Einrückungen sehe ich entspannt und lasse den Anderen den Diskussionsraum für Ihre Pros und Kontras. Was mich an Python begeistert ist die Möglichkeit Code erst einfach zu gestalten, damit es erst einfach läuft und dann in die Tiefe zu gehen um es falls nötig zu beschleunigen. Beispiel der Mittelwert-Bildung, siehe Anhang, und der daraus resultierenden Laufzeit-Optimierung mit den Möglichkeiten die Python so bietet. Und ich bin bei weitem kein Experte darin. Da geht sicherlich noch mehr. mw@linux-kwm1:~/Programming/Python/bsp >./random_average_python.py 17.96653366999999 mw@linux-kwm1:~/Programming/Python/bsp >./random_average_numba.py 2.573679684999661 mw@linux-kwm1:~/Programming/Python/bsp >./random_average_numba_parallel.py 0.793028295998738 Auch die Visualisierung mit matplotlib und pandas ist mir sehr ans Herz gewachsen und bestimmt auch vielen anderen. Deshalb habe ich meine Beispiele auch gleich angehängt, damit auch andere damit spielen können. Auf jeden Fall hilft mir Python im Arbeitsaltag sehr und hat in den vergangenen Monaten viel Mühe und Zeit bei Routine- Tätigkeiten eingespart. Jetzt beschäftige ich mich mit OpenCV und dann mit NN um in Richtung MI mein Wissen zu erweitern. Übrigens geb es gerade diese Woche im Handel vom Heise-Verlag das iX-Developer Magazin (Winter20/21) zum Thema MI und dreimal könnt Ihr raten in welcher Prog.-Sprache alle Beispiele verfasst sind. Markus
Le X. schrieb: > Ich nutze Python weil es, nach Abwägen aller Vor- und Nachteile, für > mich insgesamt das beste Gesamtpaket mitbringt. > Das Whitespace-"Feature" zähle ich aber als großen Nachteil. > Klar, ein Problem stellt es jetzt nicht dar. > Es nervt einfach nur. Oh, okay, Deine bisherigen Aussagen dazu hatte ich als weniger hart eingeschätzt.
Markus W. schrieb: > Nachdem ich mit Python3 erst vor zwei Jahren angefangen habe, > davor war Perl5 und bash mein Skripting Favorit bin ich nun > aber von Python3 zumindest recht angetan. > [...] > Da geht sicherlich noch mehr. Hast Du es mal mit Pypy ausprobiert? > Auch die Visualisierung mit matplotlib und pandas ist mir > sehr ans Herz gewachsen und bestimmt auch vielen anderen. +1 > Jetzt beschäftige ich mich mit OpenCV und dann mit NN um in > Richtung MI mein Wissen zu erweitern. Spannend... ich hacke gerade an einer Bewegungserkennung mit OpenCV auf einem RasPi4. Vor dem Hintergrund, daß ein Intel Nuc i3 mit Zoneminder und Motion dabei schon arg ins Schwitzen geraten ist, finde ich es sehr faszinierend, wie performant die ganze Geschichte mit OpenCV läuft. Dabei hat der kleine RasPi4 gerade einmal 125 BogoMIPS und der NUC immerhin 4190. Viel Spaß und Erfolg!
Sheeva P. schrieb: > Dabei hat der kleine RasPi4 gerade einmal 125 BogoMIPS und der NUC > immerhin 4190. Viel Spaß und Erfolg! Die BogoMIPS sind kein geeignetes Maß für die Verarbeitungsleistung eines Rechners, deswegen der Präfix Bogo (bogus = unecht, falsch). Der Wert dient lediglich der Kalibrierung von Busy-Loops für kurze Delays im Linux-Kernel. Speziell bei ARMs hat der Wert praktisch überhaupt nichts mehr mit der Rechenleistung zu tun: https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays Dein Raspi hat jedenfalls deutlich mehr als 125/4190 der Rechenleistung deines NUC.
Yalu X. schrieb: > Dein Raspi hat jedenfalls deutlich mehr als 125/4190 der Rechenleistung > deines NUC. Klar, aber daß so ein winziger RasPi4 mit OpenCV schneller ist als ein i3-5010U mit Zoneminder (oder noch schlimmer: Motion), finde ich trotzdem enorm beeindruckend. Übrigens habe ich mich vertan: der RasPi 3 B+ war der mit den 125 BogoMIPS, mein RasPi4 kommt auf 270. ;-)
Nick M. schrieb: >> Und -- ganz nebenbei: Ich finde es ein wenig enttäuschend, >> dass Du nicht entweder zugeben kannst, dass ich Recht habe, >> oder mir nachweist, dass ich mit meinen Aussagen Unrecht >> habe. > > Wegen dem switch / case? > Ja, hab ich doch schon beantwortet. Nur weil deinem > Empfinden nach Sprachen ähnlich sind, kannst du doch > nicht fordern, dass die das switch und case gleich > verwenden. > > [...] > > Ich find auch nicht, dass C ähnlich zu Tkl ist. [...] Nun, ich gestehe, dass ich die Differenz zwischen uns nicht ausgerechnet in DIESEM Punkt vermutet hätte. Aber gut; ich nehme es zur Kenntnis.
Beitrag #6497513 wurde von einem Moderator gelöscht.
Beitrag #6497521 wurde von einem Moderator gelöscht.
Beitrag #6497544 wurde von einem Moderator gelöscht.
Beitrag #6497547 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Das ist jetzt kein besonders gutes Beispiel, fürchte ich. Die > Perl-Entwickler haben über zehn Jahre an Perl6 entwickelt, das jetzt > seit 5 Jahren veröffentlicht ist. Da Perl6 allerdings nicht > abwärtskompatibel ist, ist der allergrößte Teil der Welt noch mit Perl5 > unterwegs, was die Perl-Entwickler vor die dumme Situation stellt, > anstatt einer Perl-Version jetzt zwei pflegen zu müssen. Irgendwann > werden sie in den sauren Apfel beißen müssen und Perl5 erst als > deprecated und dann als EOL deklarieren, oder die Entwicklung von Perl6 > einstellen müssen, um ihre Ressourcen zu konsolidieren. Ich bin gerade beim "Python-Stöbern" über diesen Thread gestolpert und wollte nur am Rande etwas korrigieren: Also Perl5 und Perl6 haben sich getrennt. Perl6 heißt jetzt Raku und ist eine eigenständige Sprache. Perl7 (Die 6 hat man jetzt aus gutem Grund übersprungen.) wurde als Nachfolger von Perl5 angekündigt und wird abwärtskompatibel sein. https://de.wikipedia.org/wiki/Raku_(Programmiersprache) https://www.perl.com/article/announcing-perl-7/?ref=alian.info Gruß Jay
Beitrag #6630771 wurde von einem Moderator gelöscht.
Danke für diesen extrem nützlichen Kommentar. Das hat sich richtig gelohnt, diesen alten Thread wieder aufzuwärmen.
Danke für diesen extrem nützlichen Kommentar. Das hat sich richtig gelohnt, diesen alten Thread wieder aufzuwärmen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.