Vorweg:
Ich finde Python toll. Ich habe gerade ein Skript zur Codegenerierung
geschrieben was in C++ oder gar in C ewig gedauert hätte.
Aber:
Dieser Zwang zur Einrückung nervt! Mal eben einen größeren Block durch
ein if-statement schützen? Dauert ewig. Dasselbe gilt für die
for-schleife. Die baut man nicht "mal eben" drum herum.
Umgekehrt natürlich das gleiche.
Klar, eine moderne IDE kann Code beliebig nach links oder rechts
einrücken. Aber: Sie kann das nicht automatisiert. In C drück ich in
Eclipse STRG-I, schon ist mein Code passend eingerückt.
In Python geht das prinzipiell nicht weil aus der Syntax nicht
hervorgeht, wie ich den Code verschachteln will.
Wenn ich Code aus einer anderen Funktione copy+paste darf ich danach
erstmal Zeile für Zeile durchgehen ob noch alles passt.
Also ehrlich, die Grundidee war ja ganz gut gemeint, aber in der Praxis
einfach nur nervig.
Schade, die Sprache ist echt mächtig.
Wie seht denn ihr das?
So, genug ausgekotzt. Jetzt gebt mir Tiernamen und erzählt mir, was ich
alles falsch mach, was ich fürn schlechter Programmierer bin und das ich
das Prinzip einfach nicht verstanden habe.
> Dieser Zwang zur Einrückung nervt! Mal eben einen größeren Block> durch ein if-statement schützen? Dauert ewig. Dasselbe gilt für> die for-schleife. Die baut man nicht "mal eben" drum herum.> Umgekehrt natürlich das gleiche.
Im Notepad++ muss ich nur die Zeilen die einzurücken sind selektieren,
drücke einmal [TAB] oder [SHIFT]+[TAB] und schon ist es erledigt.
Nervig wird es wenn man mit mehrere Programmierern zusammenarbetien muss
und der eine Tabs zum einrücken benutzt, der andere 2 Leerzeichen und
der dritte 4 Leerzeichen |-(
Das aber soll man in einem Projekt in Coding Guidelines festlegen.
bal schrieb:> Mal eben einen größeren Block durch> ein if-statement schützen? Dauert ewig. Dasselbe gilt für die> for-schleife. Die baut man nicht "mal eben" drum herum.> Umgekehrt natürlich das gleiche.
Du benutzt den falschen Editor.
Vernünftige Editoren können Einrückungen mit wenigen Tastendrücken
modifizieren.
VIM: Markieren, dann > oder < drücken
Alternativ noch eine Zahl vor dem > oder <, dann kann man mehrere Ebenen
auf einmal einrücken.
>Wenn ich Code aus einer anderen Funktione copy+paste darf ich danach
erstmal Zeile für Zeile durchgehen ob noch alles passt.
Nein. Du markierst den ganzen Block und rückst ihn entsprechend ein.
bal schrieb:> Wie seht denn ihr das?
Genauso wie du.
Diejenigen, die sagen, ein Editor könnte das automatisch, haben
vermutlich das Problem noch gar nicht verstanden. ;-) In anderen
Sprachen kann ein Editor simpel die komplette Struktur eines
gepasteten Blocks identifizieren und ihn passend einrücken; in Python
geht das prinzipbedingt nicht – oder nur dann, wenn man den Code
ausreichend mit (eigentlich nutzlosen) “pass”-Anweisungen „verziert“
hat, um gewisse Konventionen (wie „hier ist diese if-Anweisung zu
Ende“) durchzusetzen. Selbst, wenn man es mit solchen Krücken machen
könnte: fremder Code, aus dem man sich vielleicht ein paar Schnipsel
kopieren will, wird sich gewiss nicht um derartige Konventionen
scheren …
bal schrieb:> Dieser Zwang zur Einrückung nervt!
Das hat Vor- und Nachteile, aber für die meistem Leute überwiegen wohl
die Vorteile. Nim hat das Schema ja auch übernommen, und noch mindestens
eine weitere Sprache -- Erlang oder Haskell?
Und wer nur meckert, der kann ja Ruby verwenden, ist ja weitgehend
gleichwertig zu Python.
Was mich eher nervt ist, dass man in Python und Nim keine Tabulatoren
zur Einrückung verwenden soll. Nach meiner Meinung sind Tabulatoren
genau dafür erfunden worden, und was Guido oder Andreas dazu geschrieben
hatten kann mich nicht überzeugen. Aber so ist das halt.
Ich verstehe das Problem tatsächlich nicht.
Block markieren und einrücken. Bei gepasteten Code doch auch selten ein
Problem?
Und statt Tabulator halt 4 Leerzeichen und dann ist jeder zufrieden und
es funktioniert.
Finde {} überall im Text sehr ätzend seit ich die Pythonvariante kenne.
guestono schrieb:> Ich verstehe das Problem tatsächlich nicht.
Sag ich doch: die das Problem nicht verstehen, hatten es einfach
noch nie.
Ich hatte es schon oft genug.
> Bei gepasteten Code doch auch selten ein> Problem?
Du fängst dann an, die gesamte Logik hinter dem gepasteten Code
nochmal zu durchdenken.
> Finde {} überall im Text sehr ätzend seit ich die Pythonvariante kenne.
Kannst ja auch begin und end nehmen wie in Pascal. Es ist trotzdem
noch eindeutig dann. Wenn du ein Stück Python-Code dagegen komplett
„entrückst“, dann ist es hinterher nicht mehr eindeutig.
Salewski schrieb:> Und wer nur meckert, der kann ja Ruby verwenden, ist ja weitgehend> gleichwertig zu Python.
Hilft nicht viel. Warum nimmt man wohl Python? Weil es genügend
andere Leute auch nehmen, und man daher viel vorgefertigte Teile
im Netz bekommt.
Das heißt ja nicht, dass ich Python an sich schlecht fände, aber
der Zwang zu dieser Einrückerei nervt. (Dass man Code schon lange
vor Python vernünftig eingerückt hat, wenn man ihn hinterher wieder
lesen können will, steht völlig außer Frage, ganz egal, ob das in
Pascal, C, C++, Perl oder sonstwas ist.)
Jörg Wunsch schrieb:> kann ein Editor simpel die komplette Struktur eines> gepasteten Blocks identifizieren und ihn passend einrücken; in Python> geht das prinzipbedingt nicht
Doch natürlich geht das.
Neue Zeile manuell erstellen, die richtig eingerückt ist für den
folgenden Codeverlauf. Ein guter Editor macht das bei einem Druck auf
"Return".
Dann Paste.
Editor zieht alle Zeilen automatisch nach.
Salewski schrieb:> Was mich eher nervt ist, dass man in Python und Nim keine Tabulatoren> zur Einrückung verwenden soll.
Ich habe noch nie ein Pythonprogramm ohne Tab-Einrückung geschrieben.
Es funktioniert einwandfrei.
Jörg Wunsch schrieb:> Du fängst dann an, die gesamte Logik hinter dem gepasteten Code> nochmal zu durchdenken.
Nein das ist völliger Quatsch. Ich schaue mir die erste Zeile des
gepasteten Blocks an und rücke den ganzen Block um die entsprechende
Einrückung nach. Fertig. Das ist auch automatisierbar im Editor.
Ja, bei der Einrückungsphilosophie von Python scheiden sich die Geister
sehr stark. Für einige ist sie ein Grund, Python überhaupt nicht zu
verwenden, andere finden sich damit ab und versuchen sich daran zu
gewöhnen, und wieder andere finden sie sogar toll.
Für mich persönlich sind die Vorteile und die Nachteile des
Einrückungszwangs eher marginal und heben sich gegenseitig in etwa auf.
Hier die Tipps, wie man mit dem Einrückungszwang umgehen kann (teilweise
schon genannt):
Versehen eines Codeabschnitts mit einer If-, While- oder For-Zeile:
Markieren und Einrücken.
Kopieren/Einfügen: Einfügen des gesamten Blocks entsprechend der
vorangehenden oder nachfolgenden Zeile oder an der aktuellen
horizontalen Cursorposition.
Oder: Block irgendwie einfügen und nachträglich als Ganzes horizontal
zurechtrücken. Viele Editoren merken sich den eingefügten Bereich, so
dass dieser zum Verschieben nicht erst markiert werden muss.
Verwenden von Fremdcode mit anderem Einrückungsstil: Entweder so lassen
wie er ist (der Einrückungsstil muss nur in sich selbst konsistent sein)
oder ein Tool wie reindent.py verwenden.
Klar, das Ganze ist mitunter etwas lästig, kostet aber i.Allg. nur
verschwindend wenig bis gar keine zusätzliche Zeit, wenn man die
Funktionen seines Editors geschickt nutzt. Oft gibt es auch zusätzliche
Unterstützung für Python in Form von Plugins.
Dafür braucht man nicht die hässlichen, auf der deutschen Tastatur
schwer zu tippenden geschweiften Klammern wie in C. Gegen ein "end" als
Abschluss von If-, While- und For-Anweisungen hätte ich aber auch nichts
einzuwenden gehabt, wenn ich bei der Entwicklung von Python gefragt
worden wäre ;-)
Ich programmiere recht viel in Python. Wenn mich der Einrückungszwang
stören würde, wäre ich längst – wie von Stefan vorgeschlagen – auf Ruby
umgestiegen.
Salewski schrieb:> Nim hat das Schema ja auch übernommen, und noch mindestens eine> weitere Sprache -- Erlang oder Haskell?
Haskell. Allerdings ist man dort mit dem Einrückungsstil etwas freier
als in Python. Zudem müssen dort nur ganz selten größere Codeblöcke in
eine andere Einrückungsebene kopiert werden.
Hier sind weitere (zugegebenermaßen größtenteils recht exotische)
Sprachen, bei denen die Einrückung syntaktische Bedeutung hat:
http://en.wikipedia.org/wiki/Off-side_rule
Natürlich kann mein Editor der Wahl (Eclipse, an dieser Stelle bitte
einen abfälligen Kommentar) das auch.
Ganze Blöcke lustig hin und her rücken - kein Problem.
Blöd wirds halt wenn die Formatierung irgendwo mal - aus welchen Grund
auch immer - verloren geht.
Danke Jörg Wunsch, du scheinst das auch so erkannt zu haben :-)
Und die Gründe wieso die Einrückung mal wo verloren geht sind
mannigfaltig:
- Copy & Paste ausn Internet. Ganz tolle Fehlerquelle. Da weist du
erstmal nie, was du alles an Formatierung und Whitespaces mitziehst
- Copy & Paste im eigenen Code. Es kommt immer auch drauf an, wie man
Blöcke vorm Kopieren markiert. Anfang erste Zeile bis Ende letzter
Zeile? Anfang erste Zeile bis Anfang nächster nichtgewollter Zeile? Ende
letzter nichtgewollter Zeile bis Ende letzter Zeile? Usw.
Und umgekehrt kommt es dann auch darauf an wo man den Curso vorm Pasten
platziert. Schön, da kann man jetzt argumentieren: selber Schuld, pass
halt auf. Schon. Aber das ist was, da musste ich als Programmierer noch
nie aufpassen. Also ein Rückschritt.
- und der häufigste Grund: eigene Blödheit. Da bricht mir auch kein
Zacken aus der Krone wenn ich das zugeb: manchmal baut man als
Programmierer einfach Bockmist. Kommt vor.
Das war auch der Grund für meinen Eröffnungsbeitrag:
ich habe ein Skript was lange lief leicht modifiziert und (unter anderem
in eine for-Schleife gehüllt) und irgendwo ging mir eine Einrückung
verloren. Wie das ging, keine Ahnung. War der Editor Schuld, der Mond,
oder ich (wahrscheinlicher) spielt auch keine Rolle.
Ich durfte mich aber erstmal wieder ne halbe Stunde in den Algorithmus
reindenken. Am Ende habe ich ein diff zwischen altem und neuen Stand
gemacht und die Einrückungen genau verglichen. Toll!
Freut mich wenn andre anscheinend konzentrierter zu Werke gehen als ich
(oder vielleicht nur mal ein Hallo-Welt laufen lassen haben?).
Ich finde das ist eine eklatante Schwäche von Python.
Für kleine Tools und Helferlein mit paar hundert Zeilen OK.
Aber ein größeres Projekt damit? Nein danke. Zu groß die Gefahr dass
irgendjemand irgendwo was vermasselt.
PS: damit sollte ich wieder genug Angriffsfläche geliefert haben.
Ich entwickle an einer Programm(mit GUI und einigen Threads) mit knapp
200k Zeilen Code, alles in Python, mit Codestil von 8 Leuten, die vor
mir an dem Projekt gearbeitet haben.
Gerade dann, finde ich, machen genau diese Dinge python aus, einer der
Grundsätze ist ja, dass man Code einmal schreibt, aber x-mal liest.
Genau dann macht es in Python Spass und Sinn, dieses Konzept der
Einrückung(und auch noch andere Dinge), man hat unglaublich schnell
einen Überblick und(das wurde hier von Anfang an festgelegt: Einrückung
= 4 x Leerzeichen, in PyDev so konfiguriert, dass man einmal den Tab
drückt), dann liest es sich um einiges leichter wie in C(++), wo der
eine so einrückt, der andere so, da kann halt jeder machen was er will,
was echt ätzend ist(natürlich sollte er es nicht so machen, aber reviewt
schon Code, der nur für interne Aufgaben gedacht ist...?), bei Python
wird jeder dazu gezwungen es richtig zu machen, das ist in diesem
Zusammenhang, meiner Meinung nach, viel, viel besser und genau da hat
Python seine Vorteil!
gruß :)
vimperator schrieb:> Salewski schrieb:>> Was mich eher nervt ist, dass man in Python und Nim keine Tabulatoren>> zur Einrückung verwenden soll.>> Ich habe noch nie ein Pythonprogramm ohne Tab-Einrückung geschrieben.> Es funktioniert einwandfrei.
Es ist völlig wurst ob man Tabs oder Leerzeichen benutzt, aber man darf
nicht Tabs und Leerzeichen mischen! Das mag der Pythoninterpreter nicht.
Jörg Wunsch schrieb:> guestono schrieb:>> Ich verstehe das Problem tatsächlich nicht.>> Sag ich doch: die das Problem nicht verstehen, hatten es einfach> noch nie.
Ich programmiere sehr viel in Python und kenne das "Problem", aber das
Problem an dem "Problem ist:
Ich sehe überhaupt kein Problem.
Code markieren, Tab drücken, fertig. Wo ist da jetzt ein Problem?
Das ist so, als ob ihr ein neues/anderes Auto fahrt, und euch jetzt
beschwert, das ihr die Tankklappe von hand öffnen müsst, wo doch in
eurem alten Auto die Tankklappe auf knopfdruck immer aufgeplopt ist.
Sorry, aber ich kann das "Problem" echt nicht nachvollziehen :-/
bal schrieb:> Dieser Zwang zur Einrückung nervt!
Ich find den Zwang richtig geil! Alleine weil gerade Programmieranfänger
dazu gezwungen werden ihren bullshit-code vernünftig einzurücken, und
nicht sowas zu veranstalten:
1
intmein(void)
2
{
3
inta,b,c=0xDeadBeef;
4
unsignedintd[10][10];
5
for(a=0;a<10;a++)
6
for(b=0;b<10;b++)
7
d[a][b]=c;
8
return0;
9
}
Eric B. schrieb:> Nervig wird es wenn man mit mehrere Programmierern zusammenarbetien muss> und der eine Tabs zum einrücken benutzt, der andere 2 Leerzeichen und> der dritte 4 Leerzeichen |-(
Für sowas hat man Guidelines.
Es gibt in Python zwar nicht direkt ein "end" für schleifen, aber ein
"else":
1
#!/usr/bin/env python3
2
3
i=0
4
drölf=12.5
5
6
while(i<drölf):
7
#mach was
8
i=i+0.0437
9
else:
10
pass
damit könnt ihr wunderbar erkennen wo eure schleife zu ende ist, auch
wenn bei copy&paste die formatierung flöten gegangen ist.
bal schrieb:> Für kleine Tools und Helferlein mit paar hundert Zeilen OK.> Aber ein größeres Projekt damit? Nein danke. Zu groß die Gefahr dass> irgendjemand irgendwo was vermasselt.
Das irgendwer irgendwo irgendwas vermasselt, hast du immer, völlig
unabhängig von der Sprache. Ob da nun in Python einer die Einrückung
versaut, oder in C einer:
1
...
2
if(i=10)
3
{
4
...
5
}
oder wie bei Apple:
1
if(any)
2
gotofail;
3
gotofail;
4
if(any_other)
5
gotofail;
schreibt: Bloß nicht mit anderen arbeiten, die gefahr das einer was
versaut ist viel zu groß...
'tschuldigung, aber das ist nun echt kein Argument, keine größeren Tools
mit Python zu realisieren. Wie bei jeder Programmiersprache steht und
fällt das Ergebnis mit der Disziplin des Programmieres.
Kaj schrieb:> Ich sehe überhaupt kein Problem.> Code markieren, Tab drücken, fertig.
Im Prinzip ja.
In der Disneyland-LiLaLaune-Welt wo alles nach plan läuft, ja.
Aber sobald mal - wieso auch immer - in einer einzigen Zeile die
Einrückung flöten geht (so wie bei mir heute geschehen) darfst du den
ganzen Code wieder im Kopf durchspielen.
Ich mag es nicht. Ein Grund, diese Sprache zu meiden.
Dann lieber {..} oder begin .. end.
Aber eben Geschmackssache.
Auf manchen Systemen wird man gezwungen, über RS-232 noch mal schnell
mit vi zu arbeiten. Da geht das mit dem Einrücken gar nicht, es ist
äußerst umständlich.
bal schrieb:> Aber sobald mal - wieso auch immer - in einer einzigen Zeile die> Einrückung flöten geht
Deinen Editor würde ich sofort ersetzen. Er kann offensichtlich nichtmal
copy&paste.
PittyJ schrieb:> Auf manchen Systemen wird man gezwungen, über RS-232 noch mal schnell> mit vi zu arbeiten.
Ja. Schrecklich. Auf meinem Zuse Z3 ist es auch voll umständlich in
Python zu coden.
vimperator schrieb:> Ich habe noch nie ein Pythonprogramm ohne Tab-Einrückung geschrieben.> Es funktioniert einwandfrei.
Stimmt. Nach
http://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces
werden Tabs zumindest toleriert. Wobei ich vor einigen Jahren etwas
gelesen hatte, das sich klar gegen Tabs aussprach. Das Hauptargument war
wohl, dass es bei der Mischung von Tabs und Leerzeichen zu Problemen
kommt. Ich dachte eigentlich, der Text damals wäre direkt von Guido van
Rossum, aber ich finde ihn jetzt nicht mehr.
Jörg Wunsch schrieb:> Hilft nicht viel. Warum nimmt man wohl Python? Weil es genügend> andere Leute auch nehmen,
Ja, die Kids wollen Iltis-Turnschuhe und I-Jeans, weil die Kumpel die
auch alle haben. Übrigens gab es hier mal jemanden, der hatte BAE und
Free-BSD benutzt. Hieß auch Jörg.
bal schrieb:> Blöd wirds halt wenn die Formatierung irgendwo mal - aus welchen Grund> auch immer - verloren geht.
Da hast du natürlich recht.
Allerdings kann ich mich nicht erinnern, schon jemals dieses Problem
gehabt zu haben. Das liegt aber ganz sicher nicht daran, dass ich
sorgfältiger arbeiten würde als andere, sondern eher an irgendwelchen
Angewohnheiten, die ich zufälligerweise habe.
> - Copy & Paste ausn Internet. Ganz tolle Fehlerquelle. Da weist du> erstmal nie, was du alles an Formatierung und Whitespaces mitziehst
Das ist schon die erste dieser Angewohnheiten: Ich kopiere ganz selten
Code direkt von Webseiten. Kleinere Code-Fragmente tippe ich ab und
modifiziere sie dabei meist ein wenig, um sie passender zu meinem
übrigen Code zu machen (andere Variablennamen, andere Formatierung
usw.). Größere Mengen an Code lade ich als komplette Quelldateien
herunter, die dann i.All. richtig eingerückt sind.
> - Copy & Paste im eigenen Code. Es kommt immer auch drauf an, wie man> Blöcke vorm Kopieren markiert. Anfang erste Zeile bis Ende letzter> Zeile? Anfang erste Zeile bis Anfang nächster nichtgewollter Zeile? Ende> letzter nichtgewollter Zeile bis Ende letzter Zeile? Usw.
Bereiche mit ≥ 1 Zeile kopiere ich immer zeilenweise, schon alleine
deswegen, weil das im Vim am einfachsten und schnellsten geht.
> Und umgekehrt kommt es dann auch darauf an wo man den Curso vorm Pasten> platziert.
Zeilenweise kopierte Blöcke können im Vim nur vor oder nach einer Zeile
eingefügt werden, aber nicht irgendwo in der Zeilenmitte.
> - und der häufigste Grund: eigene Blödheit. Da bricht mir auch kein> Zacken aus der Krone wenn ich das zugeb: manchmal baut man als> Programmierer einfach Bockmist. Kommt vor.
Klar, jeder baut Mist, und auch mir passiert viel zu oft. Allerdings
bezieht sich bei mir dieser Mist nicht primär auf die Formatierung und
führt in Python nicht zu mehr Problemen als in C++ oder anderen
Sprachen.
Eine Fehlerquelle, über die ich in Python sehr viel häufiger stolpere,
ist die dynamische Typisierung, so angenehm diese oft ist. Das ist für
mich (zusammen mit der geringen Ausführungsgeschwindikeit) der Nachteil
Nr. 1 von Python (gleichzeitig aber auch wieder ein Vorteil ;-)).
Yalu X. schrieb:> über die ich in Python sehr viel häufiger stolpere,> ist die dynamische Typisierung, so angenehm diese oft ist. Das ist für> mich (zusammen mit der geringen Ausführungsgeschwindikeit) der Nachteil> Nr. 1 von Python
Ja, die dynamische Typisierung macht bei größeren Programmen, oder wenn
man den Code nach längerer Zeit mal wieder ansieht, schon Probleme --
bei mir bei Ruby. Python 2 vs Python 3 ist ja auch noch ein Problemchen.
Weisst Du zufällig spontan, warum
http://en.wikibooks.org/wiki/Algorithm_Implementation/Geometry/Convex_hull/Monotone_chain#Python
nur mit Python2 funktioniert?
Mein Nim Code ist ca. 40 mal schneller als der Python2 Code und sieht
fast genau so kompakt aus. Aber womöglich ist Python3 ja erheblich
schneller -- Cython und PyPy natürlich erst recht. Ich hatte übrigens
auch mal die parallele Version probiert, also obere und untere Hülle
parallel berechnet. Sieht auch kompakt aus, ist aber von der Laufzeit
momentan noch langsamer, da die Datensätze unnötiger Weise kopiert
werden.
(http://forum.nimrod-lang.org/t/483/2)
Yalu X. schrieb:> Allerdings> bezieht sich bei mir dieser Mist nicht primär auf die Formatierung und> führt in Python nicht zu mehr Problemen als in C++ oder anderen> Sprachen.>> Eine Fehlerquelle, über die ich in Python sehr viel häufiger stolpere,> ist die dynamische Typisierung, so angenehm diese oft ist. Das ist für> mich (zusammen mit der geringen Ausführungsgeschwindikeit) der Nachteil> Nr. 1 von Python (gleichzeitig aber auch wieder ein Vorteil ;-)).
Sehe ich genauso. Python hat Fehlerquellen die andere Sprachen nicht
haben (andere Sprachen haben dafür andere Fehlerquellen), aber die
Einrückung gehört eigentlich eher nicht dazu.
Zum Thema: wenn dein Editor nicht alle markierten Zeilen einrückt wenn
du Tab drückst, wirf ihn weg.
Salewski, Stefan schrieb:> 40 mal schneller als der Python2 Code
Wobei mich natürlich schon mal ein Geschwindigkeitsvergleich von Haskell
zu Python interessieren würde -- also wenn jemand zufälliger Weise
Haskell bei sich installiert haben sollte -- der Code ist ja auf der
Wikibook-Seite vorhanden:-)
Vor eingen Jahren war Haskell ja doch eher behäbig -- für mich ein
vergeschobener Grund, mich vorerst nicht mit Haskell zu beschäftigen.
Aber man sollte es schon lernen, ist irgendwie schon lehrreich, etwas
wie Latein.
vimperator schrieb:> / vs. //
Ah -- so eine Kleinigkeit!
print(convex_hull([(i//1000, i%1000) for i in range(1000000)]))
Python3 ist aber bei mir auch nicht schneller als Python2!
Salewski, Stefan schrieb:> Python3 ist aber bei mir auch nicht schneller als Python2!
Nö, ist es auch nicht. Cython ist schnell, wenn man's braucht. pypy
hilft auch oft viel kann aber einige Sachen nicht. Rechnungen kann man
oft in numpy vektorisieren, dann sind die leicht mal schneller als naiv
geschriebenes C :-)
vimperator schrieb:>> Aber sobald mal - wieso auch immer - in einer einzigen Zeile die>> Einrückung flöten geht>> Deinen Editor würde ich sofort ersetzen. Er kann offensichtlich nichtmal> copy&paste.
Schön, dass deine Welt ideal ist und immer alles funktioniert.
Meine ist es leider nicht. Ich mach' bei so einem Re-Indent auch
mal Fehler. Python ist die einzige Sprache, die ich benutze, und
die solche Fehler nicht verzeiht. In allen anderen ist die Struktur
auch so klar, sodass ich die Einrückungen automatisch nachträglich
korrigieren lassen kann.
Salewski, Stefan schrieb:> Hieß auch Jörg.
Ja, das bin ich. Und? Warum willst du mir deshalb nicht das Recht
zugestehen, Python vorrangig deshalb zu nutzen, weil ich damit
anderer Leute Code wiederverwenden kann?
Wenn ich das gerade nicht brauche, kann ich genauso gut Perl schreiben,
denn im Gegensatz zu allen, die da sofort „Igitt!“ rufen, kann ich
meinen Perl-Code genauso wie den Python-Code auch nach Jahren durchaus
noch lesen. Und, oh Wunder!, auch ganz ohne den Einrückungszwang sind
auch meine Perl-Programme genauso sauber eingerückt. Warum auch nicht?
Ich brauch dafür keine Sprache, die mich dazu zwingt, und ich würde
sogar so weit gehen zu sagen: Niemand braucht diesen Zwang, der
irgendwo ernsthaft programmiert. (Und ja, trotz Einrückung habe ich
auch schon genügend Python-Programme gesehen, die an Unleserlichkeit
den viel gescholtenen Perl- oder C-Programmen in nichts nachstanden,
sei's, weil der Autor irgendwelche Features gerade „cool“ fand oder
weil er der Meinung war, Mikro-Optimierungen einbauen zu müssen.)
Kaj schrieb:> Alleine weil gerade Programmieranfänger dazu gezwungen werden ihren> bullshit-code
Ich denke, auf diesem Niveau muss man nicht weiter diskutieren.
Jörg Wunsch schrieb:> Niemand braucht diesen Zwang,
Um Zwang geht es hier nun wirklich nicht. Der Vorteil der syntaktisch
bedeutsamen Einrückung ist einfach, dass man kein {} oder "begin" "end"
braucht, was den Code deutlich kompakter macht -- weniger Schreibarbeit,
und insbesondere bessere Lesbarkeit. Die Nachteile sind natürlich
vorhanden -- ich selbst bin eigentlich gewohnt, auf Einrückungen anfangs
gar nicht zu achten. Und eigentlich gefiel mir das Ruby "if ... end"
recht gut, insbesondere mit der Variante "do something if condition".
Die sperrigen {} für jeden Block in C, Java, Rust sind schon grauslich.
Bei Python (und Nim) meckern ja einige auch über den Doppelpunkt hinter
"if condition:". Aber wenn man drüber nachdenkt -- irgendwie sieht es
mit Doppelpunkt doch besser aus, auch wenn er syntaktisch entfallen
könnte, die Syntax ist ja durch die Einrückung der folgenden Zeile klar
definiert.
Und zu Deinem "weil es alle benutzen": Ist sicher der bequemere Weg,
insbesondee für schlichte Gemüter.
Jörg Wunsch schrieb:>> Deinen Editor würde ich sofort ersetzen. Er kann offensichtlich nichtmal>> copy&paste.>> Schön, dass deine Welt ideal ist und immer alles funktioniert.>> Meine ist es leider nicht. Ich mach' bei so einem Re-Indent auch> mal Fehler. Python ist die einzige Sprache, die ich benutze, und> die solche Fehler nicht verzeiht. In allen anderen ist die Struktur> auch so klar, sodass ich die Einrückungen automatisch nachträglich> korrigieren lassen kann.
Jörg Wunsch bringts auf den Punkt.
Hätte der vim-Mensch weiter oben meinen Beitrag gelesen wüsste er, dass
das Editor-Handling für mich nur ein Grund ist, wie die
Formatierung/Einrückung verloren gehen kann.
Ich will ja mal sehen wie der Editor deiner Wahl einen Python-Quellcode,
der - wieso auch immer - zerrissen wurde wieder lauffähig macht. Erkennt
er vielleicht aus dem Kontext die Absicht des Programmierers?
Salewski, Stefan schrieb:> Um Zwang geht es hier nun wirklich nicht.
Natürlich geht es darum. Genau zwecks diesem Zwang hab ich den Thread
aufgemacht. Um was solls denn sonst gehen?
Mir stehen keine syntaktischen Mittel zur Verfügung dem Interpreter die
von mir gewünschte Blockstruktur zu vermitteln, außer eben die
Einrückung. => Zwang.
Salewski, Stefan schrieb:> Und zu Deinem "weil es alle benutzen": Ist sicher der bequemere Weg,> insbesondee für schlichte Gemüter.
Ach geh, nicht dein Ernst oder?
OK, folgendes Gedankenexperiment: stell dir vor es gäbe die - für dich -
perfekte Programmiersprache. Genau die Logik, genau die Syntax, genau
die Bibliotheken die dir optimales Arbeiten erlauben. Allerdings handelt
es sich um eine recht exotische Programmiersprache. Mit Ausnahme der
Entwicklergemeinde benutzt sie keiner. Und leider entwicklen die auf
einem PowerPC und der Compiler/Interpreter wurde auf keine andere
Hardware portiert.
Würdest du sie benutzen? Nein? Wieso nicht?
Die Verbreitung/den Support einer Sprache in die Überlegung mit
einzubeziehen macht durchaus Sinn, auch für weniger schlichte Gemüter.
Im beruflichen Umfeld sowieso. Versuch mal bei einem
Automotive-Zulieferer mit Pascal anzukommen weil dir das so liegt... Ok.
um den Beruf geht es hier nicht, sorry für diesen kurzen Abstecher...
bal schrieb:> Hätte der vim-Mensch weiter oben meinen Beitrag gelesen wüsste er, dass> das Editor-Handling für mich nur ein Grund ist, wie die> Formatierung/Einrückung verloren gehen kann.
Meinst du mit dem vim-Mensch den vimperator oder mich?
> Ich will ja mal sehen wie der Editor deiner Wahl einen Python-Quellcode,> der - wieso auch immer - zerrissen wurde wieder lauffähig macht. Erkennt> er vielleicht aus dem Kontext die Absicht des Programmierers?
Da ich – wie schon oben geschrieben – wirklich noch nie ein Probleme
damit gehabt habe, würde es mich schon interessieren, welche weiteren
Ursachen dieser "Zerriss" (außer dem Copy/Pasten aus Web-Seiten noch)
noch haben kann.
Was den Umgang mit vermischten Tabs und Leerzeichen angeht, wurden in
Python 3 übrigens strengere Regeln eingeführt, die garantieren, dass
korrekter Python-Code unabhängig von der im Editor eingestellten
Tab-Breite immer korrekt eingerückt dargestellt wird. In Python 2 gab es
oft das Problem, dass der Versuch, vermeintlich falsch eingerückten Code
zurechtzurücken, zu wirklichen Einrückungsfehlern führte.
Am besten ist es aber nach wie vor, gemäß Guidos Ratschlag überhaupt
keine Tabs zu verwenden. Wo keine Tabs sind, können sie auch nicht
falsch dargestellt, interpretiert oder konvertiert werden.
Wer trotzdem unbedingt Blockklammern in Python möchte, bekommt er sie
hier:
http://www.pythonb.org/
[offtopic]
Salewski, Stefan schrieb:> Wobei mich natürlich schon mal ein Geschwindigkeitsvergleich von Haskell> zu Python interessieren würde -- also wenn jemand zufälliger Weise> Haskell bei sich installiert haben sollte -- der Code ist ja auf der> Wikibook-Seite vorhanden:-)
Hier sind die Zeiten in Sekunden auf einem Pentium 4 mit 3,2 GHz für 1
Million Punkte (die Gitterpunkte in {0, 1, ... 999} ^ 2), jeweils mit
int und double als Datentyp für die Koordinaten:
Yalu X. schrieb:> [offtopic]> Salewski, Stefan schrieb:>> Wobei mich natürlich schon mal ein Geschwindigkeitsvergleich von Haskell>> zu Python interessieren würde -- also wenn jemand zufälliger Weise>> Haskell bei sich installiert haben sollte -- der Code ist ja auf der>> Wikibook-Seite vorhanden:-)>> Hier sind die Zeiten in Sekunden auf einem Pentium 4 mit 3,2 GHz für 1> Million Punkte (die Gitterpunkte in {0, 1, ... 999} ^ 2), jeweils mit> int und double als Datentyp für die Koordinaten:>> int double> ——————————————————————————> C++ 0,165 0,378> Haskell 0,658 0,824> Python 2 15,527 18,420> Python 3 21,950 23,751> ——————————————————————————> [/offtopic]
Könntest du bitte deinen Python-Code posten? Würde das gerne bei mir
auch mal nachvollziehen :)
An der stelle würde ich auch noch den vergleich zu Java schön finden^^
Yalu X. schrieb:> [offtopic]> Hier sind die Zeiten in Sekunden auf einem Pentium 4 mit 3,2 GHz für 1> Million Punkte (die Gitterpunkte in {0, 1, ... 999} ^ 2), jeweils mit> int und double als Datentyp für die Koordinaten:>
1
> int double
2
> ——————————————————————————
3
> C++ 0,165 0,378
4
> Haskell 0,658 0,824
5
> Python 2 15,527 18,420
6
> Python 3 21,950 23,751
7
> ——————————————————————————
8
>
> [/offtopic]
Erstaunlich.
Hab's gerade mal mit einem Athlon II X2 245e (2.9GHz) getestet.
Mit einem Kern waren dies die Resultate:
Da diese Benchmarks nichts mehr mit dem eigentlichen Thema (Einrückung
in Python) zu tun haben, möge doch der nächste, der etwas dazu postet,
doch bitte einen neuen Thread anfangen.
Da können wir dann ohne schlechtes Gewissen weiterdiskutieren :)
Salewski, Stefan schrieb:> Um Zwang geht es hier nun wirklich nicht.
Doch, nur darum ging's (dem TE sowie mir).
Dass vernünftig geschriebene Programme eingerückt sind, ist für
mich wie für viele andere normal. Als alter Emacs-Nutzer schon
seit mehr als 20 Jahren auch für neu geschriebenen Code, denn der
Emacs bietet das schon immer an, die Einrückungen automatisch zu
organisieren. (Ja, Vim macht das natürlich auch. Nicht, dass das
jetzt jemand falsch versteht.) Bei Python muss man ihm allerdings
zuweilen etwas nachhelfen, denn ob ich bei
1
if a:
2
bla
3
if b:
4
blubb
nun in der nächsten Zeile weiter innerhalb von „if b“, innerhalb
von „if a“ oder außerhalb von beiden schreiben möchte, kann er
durch nichts erraten. Das ist halt genau die genannte
Mehrdeutigkeit. Zum Vergleich:
1
if(a){
2
bla;
3
if(b){
4
blubb;
Wenn ich jetzt eine schließende Klammer setze, ist es klar, dass
man wieder innerhalb von „if (a)“ weiterschreibt (normalerweise
auf einer neuen Zeile), bei zwei Klammern ist man außerhalb. Das
kann er völlig automatisch handhaben.
> Der Vorteil der syntaktisch> bedeutsamen Einrückung ist einfach, dass man kein {} oder "begin" "end"> braucht, was den Code deutlich kompakter macht
Halte ich für ein ziemlich dürftiges Argument. Das hätte ich zu
Zeiten eines VT100 mit 24x80 gelten lassen, aber heute? Heute ist
den meisten Leuten ja schon der K&R-Stil:
1
if(a){
2
bla;
3
blubb;
4
}
zu kompakt, und sie möchten es lieber so sehen:
1
if(a)
2
{
3
bla;
4
blubb;
5
}
Davon abgesehen, wäre ein einfaches if/else in C noch kompakter ;-)
1
if(a)bla;
2
elseblubb;
aber auch dagegen haben viele eine Aversion.
> Und zu Deinem "weil es alle benutzen": Ist sicher der bequemere Weg,> insbesondee für schlichte Gemüter.
Ich hätte dein Diskussionsniveau aufgrund früherer Äußerungen von
dir für höher gehalten. Das ist ja schon ganz knapp vor „unter der
Gürtellinie“.
bal schrieb:> Ich will ja mal sehen wie der Editor deiner Wahl einen Python-Quellcode,> der - wieso auch immer - zerrissen wurde wieder lauffähig macht. Erkennt> er vielleicht aus dem Kontext die Absicht des Programmierers?
Nein das kann er natürlich nicht.
Jedoch wird Code nicht einfach irgendwie zufällig "zerrissen".
Ansonsten solltest du, wie gesagt, dringend deinen Editor wechseln.
Den einzigen Problemfall, den ich sehen kann ist, dass alle
Leerzeichen am Zeilenanfang entfernt werden (Kann beim Pasten aus dem
Browser passieren). Sollten nur gleichmäßig in allen Zeilen Zeichen
entfernt oder hinzugefügt werden, bleibt die Semantik erhalten. Ein Fall
in dem in der einen Zeile X Zeichen und in der nächsten Zeile Y Zeichen
entfernt werden tritt nicht auf. Ansonsten wie gesagt Editor wechseln.
Jörg Wunsch schrieb:>> Um Zwang geht es hier nun wirklich nicht.>> Doch, nur darum ging's (dem TE sowie mir).
Der Begriff "Zwang" ist hier einfach völlig absurd. Durch die
syntaktischen Einrückungen kann man auf andere Konstrukte wie {}
begin/end auch bei größeren Blöcken verzichten. Das ist ein Kompromis.
Wenn Du Deine Oma besuchst, kannst Du mit dem Auto oder der Bahn fahren.
Entweder musst Du Tanken, oder dir ein Ticket kaufen -- beides ist ein
notwendiges Übel, aber kein Zwang.
Der Doppelpunkt hinter dem if ist in der Tat ein "Zwang" -- ist wie ich
schon schrieb eigentlich syntaktisch nicht notwendig, sein Fehlen wird
aber als Syntaxfehler angesehen. Da könnte ich schon verstehen wenn das
Leuten nicht gefällt.
>Halte ich für ein ziemlich dürftiges Argument. Das hätte ich zu>Zeiten eines VT100 mit 24x80 gelten lassen, aber heute?
Ja, da kann man sicher verschiedener Meinung sein. Oft entscheidet wohl
die Gewohnheit, {} kennt man von C, das findet man dann ganz OK und
übernimmt es halt, wie bei Java, Rust usw. In Büchern, oder bei
Pseudocode im Netz, etwa Wikipedia/Wikibooks, habe ich aber oft
Strukturierung durch Einrückungen geshen, da wird es dann eher
akzeptiert. Guide van Rossum wurde anfangs ja für seine Entscheidung
auch teils stark kritisiert, aber dann waren die Meisten doch mit der
Entscheidung einverstanden. Übrigens gab es mal eine Python-Variante, wo
ein endif oder so erlaubt war -- hat dann aber niemend benutzen wollen.
Mit den 4k Monitoren sind die {} auch etwas akzeptabler geworden, darauf
sieht auch das sperrige Java nicht mehr ganz so schlimm aus.
Ich weiss jetzt nicht, ob es hier jemand erwähnt hat, aber ein
entscheidender Kritikpunkt zum Thema Einrückung bei Python ist ja, dass
man allein durch Leerzeichen die Semantik verändern und somit
schwerwiegende Fehler erzeugen kann. Das ist wohl war, aber Fehler kann
man an vielen Stellen machen. Ich mache manchmal ein diff mit dem
letzten Backup, um zu überprüfen, wo ich was verändert habe.
>> Und zu Deinem "weil es alle benutzen": Ist sicher der bequemere Weg,>> insbesondee für schlichte Gemüter.>Ich hätte dein Diskussionsniveau aufgrund früherer Äußerungen von>dir für höher gehalten. Das ist ja schon ganz knapp vor „unter der>Gürtellinie“.
Na das ist doch eine treffende Aussage gewesen. Dass "schlichte Gemüter"
jetzt nicht auf dich persönlich bezogen war, ist ja wohl
selbstverständlich. Und der bequemere Weg muss ja nicht immer schlecht
sein...
Aber grundsätzlich behagt es mir nicht sonderlich, dass hier so oft
platte Antworten wie "nimm C", "nimm Python", nimm "Eagle", nimm
"Ubuntu" -- weil es alle benutzen, kommen. Dass der Rat gutgemeint und
eventuell auch angebracht sein kann ist klar, aber oft sollte man sich
schon etwas differenzierter äussern. Und schlimm wird es, wenn dann
selbst Leute wie Yalu indirekt als Spinner bezeichnet werden, weil sie
sich mit Haskell beschäftigen. War erst vor ein paar Monaten. Aber das
kennst Du womöglich mit BAE und BSD selbst.
@Yalu: Danke für den Test -- Haskell ist ja in diesem Fall doch recht
fix und liegt etwa auf dem Niveau von Nim. Eine Ausrede weniger, mich
nicht mit Haskell zu beschäftigen. Und ja, mir ist klar dass solche
Mikro-Benchmarks generell nicht sehr aussagekräftig sind.
Jörg Wunsch schrieb:> Normalerweise eine Anweisung pro Zeile, aber dort plötzlich nicht.
Python hat mehrere Konstrukte, in denen mehrere Anweisungen (auch
scheinbar) in einer Zeile stehen. z.B. ternärer Operator oder List
comprehensions.
Außerdem kann man in Python auch Semikolons setzen zum Abschluss eines
Statements.
"Nur eine Anweisung pro Zeile" galt nie.
vimperator schrieb:> Jörg Wunsch schrieb:>> Normalerweise eine Anweisung pro Zeile, aber dort plötzlich nicht.>> Python hat mehrere Konstrukte, in denen mehrere Anweisungen (auch> scheinbar) in einer Zeile stehen. z.B. ternärer Operator oder List> comprehensions.
Das sind aber alles keine Statements, sondern Expressions. Die können
zum Beispiel nie einer lokalen Variable einen neuen Wert zuweisen oder
so.
> Außerdem kann man in Python auch Semikolons setzen zum Abschluss eines> Statements.>> "Nur eine Anweisung pro Zeile" galt nie.
Das ist richtig. Das ist nicht inkonsistent, das ist überall in der
Sprache so.
Salewski, Stefan schrieb:> Um Zwang geht es hier nun wirklich nicht. Der Vorteil der syntaktisch> bedeutsamen Einrückung ist einfach, dass man kein {} oder "begin" "end"> braucht, was den Code deutlich kompakter macht -- weniger Schreibarbeit,> und insbesondere bessere Lesbarkeit.
Wie bitte?
Ich halte Python für eine grottenschlechte Sprache, eben weil sie das
simple Erscheinungsbild zum Teil der Syntax macht. Formatfreiheit in der
Quelle ist nicht nur ein Stück Freiheit, sondern auch ein Stück
Sicherheit - ja auch wenn man dafür eben begin und end oder { und } oder
sonst irgend eine Art Spezialbezeichner benutzen muß. Genau DADURCH kann
der Compiler auch wesentlich besser Schreibfehlern auf die Spur kommen.
Und das Argument 'kompakterer Code' lasse ich auch nicht gelten. Ein
heutiger Compiler kann Abertausende von 'begin's pro Sekunde durchziehen
und gut lesbar ist eine solche Quelle mit {} und Co. ebenfalls -
vorausgesetzt, der Schreiber hat einigermaßen diszipliniert geschrieben.
Bleibt die Faulheit: "weniger Schreibarbeit,.." als einziges Argument
übrig. Aber das ist zumindest für mich gar kein Argument.
Nein, sowas wie syntaktische Blockzugehörigkeiten per Einrückung zu
organisieren, ist eine grottenschlechte Idee - jedenfalls heutzutage.
Das war mal zu Zeiten von Assembler und Fortran anders, aber damals auf
Grund geringerer Hardware-Ressourcen.
Jörg Wunsch schrieb:> Heute ist den meisten Leuten ja schon der K&R-Stil:> if (a) {> bla;> blubb;> }>> zu kompakt,..
Ähem.. nee, nicht zu kompakt, sondern zu unleserlich. Mit den
Blockmarkierungen in gleicher Spalte wird es leserlicher. Wir Menschen
sind halt "Augentiere".
> und sie möchten es lieber so sehen:> if (a)> {> bla;> blubb;> }
noch anders:
if (a)
{ bla;
blubb;
}
so wird's lesbarer und zugleich einigermaßen kompakt.
W.S.
W.S. schrieb:> if (a)> { bla;> blubb;> }
uargh ;D
--
Nebenbei finde ich ja auch die Syntax von so einer Sprache ziemlich
egal. Fällt das bei nichttrivialen Programmen wirklich in's Gewicht ob
man jetzt da paar Tabs schreibt oder irgendwelche Klammern oder so? Das
ist doch total egal, sobald man sich da ein bisschen reingedacht hat.
Viel wichtiger sind Dinge wie Typsystem und Objektmodell und sowas.
Die Einrückungssyntax von Python wird regelmäßig nur von Leuten
kritisiert die noch nie ernsthaft mit Python gearbeitet haben und sich
daher nur realitätsferne Szenarien ausdenken können (wie zum Beispiel
der Kollege weiter oben dem über Nacht immer die Heinzelmännchen
heimlich den Code "zerreißen").
Nichts davon ist relevant. Es sind theoretische Gedankenkonstrukte die
mangels realer Existenz notwendigerweise nur einer allzu lebhaften
Phantasie entsprungen sein können, einer Phantasie die auf Hochtouren
laufen muss beim verkrampften Versuch eine Kritik zu formulieren nur um
der Kritik willen, nicht wissend (aufgrund fehlender Sachkenntnis und
Erfahrung) was man überhaupt kritisieren soll. Lachhaft.
Es gibt sicherlich genug kritikwürdige oder umstrittene Aspekte in
Python, die Einrückungssyntax jedoch gehört nicht dazu, über deren
Vorteile sind sich alle einig.
Fragt mal nen echten Python-Programmierer (zum Beispiel auf ner Python
Mailingliste oder in nem einschlägigen Forum oder IRC channel) ob man
nicht doch lieber die Syntax ändern und auf {} umstellen sollte weil
doch nachts wenn alle schlafen und keiner hinschaut immer der Code
zerrissen wird.
Bernd K. schrieb:> Die Einrückungssyntax von Python wird regelmäßig nur von Leuten> kritisiert die noch nie ernsthaft mit Python gearbeitet haben
Besser kann man es eigentlich kaum zusammenfassen.
-- Vimperator, der sehr viel in Python, aber auch sehr viel in C/C++
programmiert.
Bernd K. schrieb:> Die Einrückungssyntax von Python wird regelmäßig nur von Leuten> kritisiert die noch nie ernsthaft mit Python gearbeitet haben
Bereits das Eröffnungsposting dieses Threads widerspricht deiner
Theorie komplett. Es ist ausschließlich deshalb geschrieben worden,
weil derjenige ernsthaft mit Python arbeitet. Sonst wäre er nie
bis an diese Stelle gekommen.
Es ist schön, wenn man sich sein Weltbild immer so zurechtbiegen
kann, dass die Welt da reinpasst.
> Nichts davon ist relevant.
Klar, all das, was da nicht reinpasst, deklariert man einfach als
„irrelevant“, damit hat sich die Sache erledigt.
Ich kenne eine Staatsführung, die hat mal ähnlich argumentiert wie
du. Es gibt sie inzwischen nicht mehr.
> Fragt mal nen echten Python-Programmierer (zum Beispiel auf ner Python> Mailingliste
Klar, weil das ja auch die beste Referenz für jemanden ist, der da
objektiv argumentieren wird.
Übrigens: keiner will diese Syntax ernsthaft ändern. Schon deshalb
nicht, weil man ja dann den bestehenden Code wieder bloß nicht
weiterverwenden kann. Schon die, teilweise allerdings wirklich
recht willkürlich inkompatibel anmutenden, Änderungen von Python 2
nach Python 3 finden ja selbst in der Python-Gemeinde nur sehr
widerspenstige Aufnahme. Da braucht nun niemand argumentieren, dass
man doch die Sprachsyntax jetzt noch so grundlegend ändern könnte
oder sollte. Das ist völlig unrealistisch (dann kann man auch gleich
etwas ganz anderes machen, Ruby vielleicht). Trotzdem darf man, auch
als Python-Nutzer, diese Syntax, naja, wenig gelungen finden, auch
wenn das eingefleischte Python-Fans nicht verstehen können.
Ich komme mit Python zurecht, ich benutze es, vielleicht nicht täglich,
aber häufig. Dennoch finde ich die Leereichenmanie nach wie vor das
mit Abstand grässlichste Detail dieser Sprache.
Jörg Wunsch schrieb:> Bernd K. schrieb:>>> Die Einrückungssyntax von Python wird regelmäßig nur von Leuten>> kritisiert die noch nie ernsthaft mit Python gearbeitet haben>> Bereits das Eröffnungsposting dieses Threads widerspricht deiner> Theorie komplett. Es ist ausschließlich deshalb geschrieben worden,> weil derjenige ernsthaft mit Python arbeitet. Sonst wäre er nie> bis an diese Stelle gekommen.
Das sehe ich nicht so. Der TO ist offensichtlich Python-Anfänger und
würde sich bestimmt auch selbst so bezeichnen. Kein Mensch der nach
meiner Definition von "ernsthaft" ernsthaft mit Python arbeitet kann
nicht in seinem Editor einen Block einrücken ohne das für jede Zeile
einzeln zu machen (das soll kein Angriff auf den TO sein, aber sowas
lernt man einfach wenn man etwas länger mit der Sprache arbeitet).
> Übrigens: keiner will diese Syntax ernsthaft ändern.
Das ist natürlich 'ne Erkenntnis scnr
1
>>> from __future__ import braces
2
File "<stdin>", line 1
3
SyntaxError: not a chance
> Schon die, teilweise allerdings wirklich> recht willkürlich inkompatibel anmutenden, Änderungen von Python 2> nach Python 3 finden ja selbst in der Python-Gemeinde nur sehr> widerspenstige Aufnahme.
Naja, eigentlich sind die meisten dieser Änderungen sehr gut, und
zumindest bei den Leuten die ich so kenne wird das auch so aufgefasst.
Diese Bytes/String-Trennung war zum Beispiel schon lange überfällig, und
ist nun mal inkompatibel zum alten System. Dass sich der Umstieg so
lange hinzieht ist schade, war aber vorhersehbar und wurde auch so
vorhergesehen.
Sven B. schrieb:> Naja, eigentlich sind die meisten dieser Änderungen sehr gut, und> zumindest bei den Leuten die ich so kenne wird das auch so aufgefasst.
Ich kenne eingefleischte (um nicht zu sagen evangelistische)
Python-Programmierer, die Python 3 keine Chance geben. Nein, ich
stimme da nicht zu, sehe aber auch, dass Python 3 sich immer noch
schwer tut, sich durchzusetzen. Schwerer als seinerzeit der Übergang
von Perl 3 auf 4 (als sie den OO-Ansatz eingeführt haben und auch
sonst einiges umgekrempelt).
Ich bemühe mich, Scripte nach Möglichkeit zwischen beiden Versionen
kompatibel zu halten. Dabei fallen einem gelegentlich schon ein paar
Willkürlichkeiten auf, die man sich im „fortgeschrittenen Alter“, in
dem Python mittlerweile ist, besser hätte klemmen können. Es gibt
genügend andere Dinge, die auch nicht ganz so die „reine Lehre“ sind
(warum hat man zum Ermitteln der Länge eines Strings eine Funktion
und keine Methode des string-Objekts?), die man aber nicht geändert
hat. Solche Dinge wie raw_input vs. input hätte man einfach auch nur
so lassen sollen, wie sie nun einmal historisch gewachsen waren.
> Der TO ist offensichtlich Python-Anfänger
Du hast ihm jedoch mit deiner Ausdrucksweise die Ernsthaftigkeit seines
Tuns abgesprochen. Das ist 'ne andere Nummer.
Du hast dich einfach bloß an die Macken der Sprache gewöhnt (was ja
OK ist, wenn man sich an allem aufreibt, hat das auch keinen Sinn),
aber tust nun so, als wären die Macken eigentlich Vorzüge.
Wer neu hinzu kommt, ist dagegen schneller dabei, eine Macke auch
als solche zu benennen. Das tut der Ernsthaftigkeit seiner Absicht,
die Sprache zu nutzen, keinen Abbruch.
Wie ich schon schrieb: meiner Meinung nach ist der Leerzeichen-Mist
die Fehlentscheidung im Design von Python schlechthin. Das lässt
sich jedoch nicht mehr ändern, wir müssen einfach damit leben.
Ich habe mal spaßeshalber dieses "Python with Braces" ausprobiert:
http://www.pythonb.org/
Das Ganze funktioniert recht gut, und da die Klammern und Semikola
gleich wie in C verwendet werden, kann man die Editorfunktionen für die
automatische Einrückung nutzen, ohne sie speziell an die Pythonsyntax
anzupassen.
Ein weitere Vorteil dieser Syntax besteht darin, dass lange Zeilen
überall dort umgebrochen werden können, wo dies auch in C möglich wäre.
Im klassischen Python geht dies ohne Fortsetzungs-Backslash nur
innerhalb von geklammerten (Teil-)Ausdrücken.
Einen kleinen Haken, der sich aber in der Praxis kaum bemerkbar machen
wird, hat die Sache: In Python ist der dem Schlüsselwort except
folgende Ausdruck optional. Da dieser Ausdruck theoretisch mit einer
geschweiften Klammer (Dictionary-Literal) beginnen kann, ist die Syntax
an dieser Stelle für den Parser mehrdeutig. Deswegen kann man kein
leeres except verwenden, sondern muss immer einen Ausdruck (im
einfachsten Fall einfach Exception) dahinterscheiben.
Fremdcode kann problemlos als vorkompiliertes Modul (.pyc-Datei)
eingebunden werden. Trotzdem wäre zusätzlich ein Konvertierungstool
zwischen beiden Syntaxen ganz nützlich, was aber mit begrenztem Aufwand
realisierbar sein sollte.
Hier ist ein kleines Beispiel, einmal mit Braces und einmal klassisch:
Mal ganz ehrlich: Wenn man die Python-Syntax gewohnt ist, sieht die
linke Variante ja schon ein Bisschen schaurig aus. Von Weitem denkt man
wegen der dominierenden Klammern sofort an C, Java o.ä., beim genaueren
Hinsehen entdeckt man die dazwischen eingeflochtenen Python-Konstrukte.
So etwas kann das Programmiererhirn ordentlich durcheinanderbringen :)
Ich würde jedenfalls nicht zur Braces-Syntax wechseln wollen, da ist mir
einfach zuviel syntaktisches Rauschen darin enthalten. Aber für
diejenigen, die mit der Einrückungsphilosophie von Python überhaupt
nicht zurechtkommen, ist das ja vielleicht eine willkommene Alternative.
Jörg Wunsch schrieb:> Schon die, teilweise allerdings wirklich recht willkürlich> inkompatibel anmutenden, Änderungen von Python 2 nach Python 3 finden> ja selbst in der Python-Gemeinde nur sehr widerspenstige Aufnahme.
Es gibt zwei Möglichkeiten, eine Programmiersprache zu erweitern:
1. So, dass sie immer abwärtskompatibel zu allen bisherigen Versionen
ist (wie bspw. in C). Dann meckern die Leute, weil Jahrzehnte alte
Konzeptfehler bis heute nicht beseitigt worden sind.
2. So, dass hin und wieder reiner Tisch gemacht wird und dabei Altlasten
und Inkonsistenzen über Bord geschmissen werden (wie in Python). Dann
meckern die Leute, dass sie ihren alten Code anpassen müssen.
Eigentlich sollten Programmiersprachen überhaupt nicht weiterentwickelt
werden ;-)
Jörg Wunsch schrieb:> Wie ich schon schrieb: meiner Meinung nach ist der Leerzeichen-Mist> die Fehlentscheidung im Design von Python schlechthin. Das lässt> sich jedoch nicht mehr ändern, wir müssen einfach damit leben.
Also ich bin mir nicht völlig sicher -- aber ich denke doch das kann man
ändern: Einfach eine alternative Syntax zulassen, etwa mit "endif". Gab
es ja sogar mal ansatzweise. Jedenfalls in der Nimrod-Doku hatte ich
irgendwo gelesen, dass eine alternative Syntax denkbar wäre -- Andreas
schrieb sinngemäß, dass es das grösste Problem war, die Blockstruktur
anhand der Einrückungen sicher zu erkennen, die alternative Syntax wäre
danach recht einfach machbar. Jetzt aber Schluss von meiner Seite, wir
finden eh keinen Konsenz, und ich bin ja selbst nicht der größte Fan der
Einrückungen.
Es wurde geschrieben:
> Der Vorteil der syntaktisch> bedeutsamen Einrückung ist einfach, dass man kein {} oder "begin" "end"> braucht, was den Code deutlich kompakter macht -- weniger Schreibarbeit,> und insbesondere bessere Lesbarkeit.
Leute, denkt doch mal bitte ein wenig nach über eure "Argumente"! Wir
schreiben das Jahr 2014, wo Programmierer Bildschirme vor der Nase
haben, so groß wie Fußballfelder! Da kommt ihr mit so ollen Kamellen als
Argument von Anno Dunnemals wie der "Kompaktheit", welches vielleicht
noch eine Relevanz hatte als Programmierer sich unter MS-DOS mit 80
Zeichen auf 20 Zeilen bei schlechten Rasterfonts herumquälen mussten.
So ein Argument könnte man heute höchstens noch gelten lassen, wenn
jemand seine Programmierarbeit auf einem Smartfon im Omnibus verrichten
möchte und selbst dort hat es inzwischen mehr Zeilen, als noch unter
MS-DOS anno 198x bis 199x, solange es die Augen halbwegs noch mitmachen.
Ich möchte mal sehen was los wäre, wenn das nächste C99, C11 als C99+,
C11+ "Update" mit Abschaffung des Klammerzwangs und dafür Einrückregeln
reformiert daherkommen würde. Die Lesbarkeit wäre kaum bis gar nicht
besser (eher schlechter) und dem C-Fehlerteufel wäre eine neue
Steilvorlage geliefert, auch und gerade in Bezug auf die Verwendung
schon mal geschriebenen Codes.
Nun bin ich als "unechter" Python-Programmierer, der eher noch am Anfang
steht in Sachen Python, vielleicht nicht der Kronzeuge für diese
Diskussion hier. Aber mir macht es Bauchschmerzen, wenn die
Codeausführung von solchen Trivialitäten gefährlich und hinterfotzig
beeinflusst wird. Da ist mir selbst das geschwätzige 'Begin End' in
Pascal noch lieber. Das gibt dem Text augenblicklich (und das ist
wörtlich zu nehmen) Struktur ohne erst groß Regeln hinterfragen zu
müssen.
Kann das sein, dass sich diesen Käse hier mal wieder Spezies ausgedacht
haben, die vi als Editor schon mit der Muttermilch verabreicht bekommen
haben, Unix als das allein selig machende OS sehen, einen Hipsterbart
tragen, sich für die Über-Über-Programmierer halten, aber noch nie im
Leben eine Schlagbohrmaschine bedient haben? Soll heißen, irgend welche
permanent in Quellcode vergeistigte Nerds, für die jedes praktisch
auftauchende Problem einen flotten, kessen Spruch auf den Lippen haben,
aber sich vor wirklicher greifbarer Arbeit gerne wegducken? ("2 Klammern
vermieden = viel Arbeit gespart = Tag ist gerettet")
Gott lass diesen Menschen einmal, nur einmal echte Emotionen zuteil
werden oder alternativ bitte mal ins Rentenalter kommen.
Meine 2 Eurocents dazu
unechter Python-Programmierer schrieb:> Kann das sein, dass sich diesen Käse hier mal wieder Spezies ausgedacht> haben, die vi als Editor schon mit der Muttermilch verabreicht bekommen> haben,
Nein, überhaupt nicht. Guido verwendet auch Emacs.
Yalu X. (yalu) (Moderator) schrieb:
unechter Python-Programmierer schrieb:
>> Kann das sein, dass sich diesen Käse hier mal wieder Spezies ausgedacht>> haben, die vi als Editor schon mit der Muttermilch verabreicht bekommen>> haben,> Nein, überhaupt nicht. Guido verwendet auch Emacs.
Wer um alles in der Welt ist denn "Guido"?
Beim Staubsaugerkauf interessiert mich manches, wie z.B. die Leistung,
das Staubrückhaltevermögen, das Design, natürlich der Preis. Was mich
bisher nie interessierte ist der Name des Entwicklers des Staubsaugers.
Guido = Python Erfinder, Designer ???
unechter Python-Programmierer schrieb:> Guido = Python Erfinder, Designer ???
Genau, nämlich dieser hier:
http://de.wikipedia.org/wiki/Guido_van_Rossum> Was mich bisher nie interessierte ist der Name des Entwicklers
Klar, Namen sind ja schließlich Schall und Rauch. Stattdessen machst du
dir Gedanken über das wirklich Essentielle, nämlich welchen Texteditor
der Entwickler benutzt.
Das geht mir aber ganz ählich: Du kannst mir ein Bild eines berühmten
Hollywood-Schauspielers zeigen. Die Chance ist verschwindend gering,
dass ich dir seinen Namen nennen kann, weil das für mich keinerlei
Relevanz hat. Schon eher von Interesse ist es für mich zu wissen,
welches Auto er privat fährt ;-)
Hi,
Eric B. schrieb:> Nervig wird es wenn man mit mehrere Programmierern zusammenarbetien muss> und der eine Tabs zum einrücken benutzt, der andere 2 Leerzeichen und> der dritte 4 Leerzeichen |-(
ja, sowas nervt.
Manche (viele?) unterscheiden zwischen Einrücken und Formatieren. Sie
rücken mit Tabs ein und formatieren mit Leerzeichen. Mache ich auch so
(Java, C, C++, kein Python).
Der Anfang eines Statements wird hierbei eingerückt. Ist das Statement
länger (z.B. Parameterliste), wird umgebrochen, eingerückt, aber dann
mit Leerzeichern so formatiert, daß die Parameter alle schön
untereinander stehen usw. Dann kann jeder seinen Tabstopp im Editor so
konfigurieren, wie er will, und es paßt immer.
Im Übrigen halte ich einen Tabstopp von 2 bzw. 2 Spaces zum Einrücken
für sowas von krank. Sieht aus wie Matsch.
Bei uns gibt es einen Guide: innerhalb einer Datei muß das
Einrücken/Formatieren einheitlich bleiben, egal wie. Niemand will einem
Entwickler eine andere Religion aufzwingen. Dasselbe gilt dafür, wo die
{ und } gesetzt werden: selbe Zeile oder in der nächsten.
Grüße, Markus
>> if (a) {>> bla;>> blubb;>> }
[...]
>> if (a)>> {>> bla;>> blubb;>> }
[...]
>> if (a)> { bla;> blubb;> }
Genau das ist für mich eher ein Grund, Python zu nehmen. Grad' bei der
letzten Variante stellen sich bei mir die Zehennägel auf. Immer nervig,
fremden Code durch "indent" zu jagen. Aber wenigstens gibt es so ein
Tool.
Ich persönlich finde fremden Python Code i.A. besser lesbar als fremden
C bzw C++ Code... was aber nicht allein an den fehlenden Klammern liegt.
Yalu X. (yalu) (Moderator) schrieb:
>> Was mich bisher nie interessierte ist der Name des Entwicklers> Klar, Namen sind ja schließlich Schall und Rauch. Stattdessen machst du> dir Gedanken über das wirklich Essentielle, nämlich welchen Texteditor> der Entwickler benutzt.
Immer der Reihe nach. Zuerst mal ist es euer Thread hier, der die
Diskussion um "Einrückung" vom Zaun brach, also ich war's nicht und
Anzahl sowie Beteiligung zeigt mir doch, "Houston, wir haben ein
Problem!" - vielleicht kein wirklich großes Problem, aber eines das bei
einigen das Nervenkostüm öfter mal strapaziert.
Dein Link zu pythonb (kannte ich bisher nicht. Vielen Dank!) zeigt
zudem, es gibt Findige, die dem Einrückzwang diesbezüglich durch
Angleichen an C begegnen wollen. Ob das der Königsweg ist, ob ich mich
selber künftig lieber an das eine oder das andere gewöhne, weiß ich noch
nicht. Gewöhnen kann ich mich wenn es sein muss an fast alles (solange
Josef G. nicht zufällig das Design von Python übernimmt. Denn dann würde
ich vermutlich nur noch Bahnhof verstehen).
Jörg Wunsch schrieb:> Sven B. schrieb:>> Naja, eigentlich sind die meisten dieser Änderungen sehr gut, und>> zumindest bei den Leuten die ich so kenne wird das auch so aufgefasst.>> Ich kenne eingefleischte (um nicht zu sagen evangelistische)> Python-Programmierer, die Python 3 keine Chance geben.
Es gibt immer komische Typen.
> Es gibt> genügend andere Dinge, die auch nicht ganz so die „reine Lehre“ sind> (warum hat man zum Ermitteln der Länge eines Strings eine Funktion> und keine Methode des string-Objekts?), die man aber nicht geändert> hat.
Auch auf die Gefahr hin, wieder des "du findest das eh alles gut"
bezichtigt zu werden: Das hat schon seinen Sinn so. "Objekt mit Länge"
ist in Python ein generelles Konzept, welches von str implementiert
wird; Typen, die dieses Konzept unterstützen, implementieren __len__().
Es gibt also eine Methode, die von jedem beliebigen Objekt mit einer
Länge diese Länge ermittelt, und da die "magischen" Namen in Python alle
__foo__() heißen, heißt die halt __len__(). Weil das ein bisschen
unschön aussieht, gibt es len(), was einfach nur diese Methode aufruft.
Dieses Design ist also beabsichtigt und keine Abweichung von der "reinen
Lehre", sondern Teil derselben.
> Solche Dinge wie raw_input vs. input hätte man einfach auch nur> so lassen sollen, wie sie nun einmal historisch gewachsen waren.
Ja, vielleicht. Die Python-Leute sind da halt radikal. Aber deshalb ist
die Sprache halt großteils schön aufgeräumt und nicht so ein Chaos wie
C++. Aber klar, das hat Vor- und Nachteile.
>> Der TO ist offensichtlich Python-Anfänger>> Du hast ihm jedoch mit deiner Ausdrucksweise die Ernsthaftigkeit seines> Tuns abgesprochen. Das ist 'ne andere Nummer.
Warum sollte das so sein? Jeder der ernsthaft etwas tut war irgendwann
mal neu auf dem Gebiet ...
> Du hast dich einfach bloß an die Macken der Sprache gewöhnt (was ja> OK ist, wenn man sich an allem aufreibt, hat das auch keinen Sinn),> aber tust nun so, als wären die Macken eigentlich Vorzüge.
Das verstehe ich nicht. Welche Dinge, die deiner Meinung nach Macken
sind, bezeichne ich als Vorzüge? Ich habe eigentlich nur gesagt dass a)
die Syntax einer Sprache ziemlich egal ist, solange man die mal
einigermaßen kann und b) Python 3 gegenüber 2 einige klare Vorteile
bietet (Strings vs. Bytes!). Die zweite Aussage ist eigentlich genau das
Gegenteil von "an Macken gewöhnt", denn wäre ich das, fände ich ja
radikale Änderungen nicht gut.
> Wer neu hinzu kommt, ist dagegen schneller dabei, eine Macke auch> als solche zu benennen.
Einerseits ja, andererseits versteht man manche Design-Entscheidungen
aber oft auch einfach erst nach einer Weile. Klar ist das ein schmaler
Grat zwischen "versteht man erst nach einer Weile" und "ist komisch
entworfen", aber die len()-Sache ist meiner Meinung nach ein klares
Beispiel für ersteres: das findet eigentlich jeder erstmal komisch, aber
wenn man die Idee dahinter mal gehört hat, ist klar warum das so gemacht
wurde.
> Das tut der Ernsthaftigkeit seiner Absicht,> die Sprache zu nutzen, keinen Abbruch.
Nö, hab ich auch nicht behauptet. Nur, dass man den Titel "ernsthafter
Anwender" (zumindest im Sinne von "erfahrener Anwender", so wurde der
Begriff nämlich hier benutzt) nicht in der ersten Sekunde erwirbt, in
der man versucht, die Sprache für ernsthafte Zwecke einzusetzen.
> Wie ich schon schrieb: meiner Meinung nach ist der Leerzeichen-Mist> die Fehlentscheidung im Design von Python schlechthin. Das lässt> sich jedoch nicht mehr ändern, wir müssen einfach damit leben.
Ich habe für diese Meinung Verständnis, verstehe aber nicht, warum diese
Design-Entscheidung so relevant ist. Das ist wie mit den Strichpunkten
in C++, im Endeffekt sind die auch total bescheuert (Zeilenende als
Strichpunkt interpretieren und \ als "Zeilenende ohne Strichpunkt" wäre
tausendmal einfacher), aber nachdem man sich initial mal dran gewöhnt
hat, ist es einfach völlig egal und hat keinerlei Einfluss mehr auf das,
äh, "Programmiererlebnis" mit der Sprache. Zumindest geht mir das so.
W.S. schrieb:> Ich halte Python für eine grottenschlechte Sprache, eben weil sie das> simple Erscheinungsbild zum Teil der Syntax macht. Formatfreiheit in der> Quelle ist nicht nur ein Stück Freiheit, sondern auch ein Stück> Sicherheit - ja auch wenn man dafür eben begin und end oder { und } oder> sonst irgend eine Art Spezialbezeichner benutzen muß. Genau DADURCH kann> der Compiler auch wesentlich besser Schreibfehlern auf die Spur kommen.
Genau das Gegenteil ist der Fall. Bei der Klammer-Schreibweise gibt es
eine Merhdeutigkeit. Wenn ich Code anschaue, erfasse ich dessen Struktur
primär aus der Einrückung. Der Compiler (z.B. in C) dagegen hält sich
strengstens an die Klammern. Passen die beiden aus irgendeinem Grund
nicht zusammen, passieren wundersame Dinge, und erst beim genauen
Drüberschauen findet man irgendwann die Diskrepanz. Bei Python dagegen
gibt es dieses Problem nicht, da der Interpreter genau wie ich nach den
Einrückungen geht.
> Und das Argument 'kompakterer Code' lasse ich auch nicht gelten. Ein> heutiger Compiler kann Abertausende von 'begin's pro Sekunde durchziehen> und gut lesbar ist eine solche Quelle mit {} und Co. ebenfalls -> vorausgesetzt, der Schreiber hat einigermaßen diszipliniert geschrieben.
Und da liegt eben der Knackpunkt. In C mußt du voraussetzen, daß der
Schreiber diszipliniert war. In Python ist er ganz automatisch dazu
gezwungen, weil's sonst einfach nicht funktioniert.
Jörg Wunsch schrieb:> Du hast dich einfach bloß an die Macken der Sprache gewöhnt (was ja> OK ist, wenn man sich an allem aufreibt, hat das auch keinen Sinn),> aber tust nun so, als wären die Macken eigentlich Vorzüge.>> Wer neu hinzu kommt, ist dagegen schneller dabei, eine Macke auch> als solche zu benennen. Das tut der Ernsthaftigkeit seiner Absicht,> die Sprache zu nutzen, keinen Abbruch.
Vielleicht solltest du auch bedenken, daß es nicht jeder als "Macke"
sieht, an die man sich "gewöhnen" müßte. Ich habe das z.B. nie als
negativ empfunden.
unechter Python-Programmierer schrieb:> Leute, denkt doch mal bitte ein wenig nach über eure "Argumente"! Wir> schreiben das Jahr 2014, wo Programmierer Bildschirme vor der Nase> haben, so groß wie Fußballfelder!
Ich muß oft auch an einem Laptop mit 15"-Bildschirm in unsäglichem
16/9-Format arbeiten. Da ist die vertikale Größe geringer als an meinem
PC aus dem letzten Jahrtausend.
Markus schrieb:> Hi,>> Eric B. schrieb:>> Nervig wird es wenn man mit mehrere Programmierern zusammenarbetien muss>> und der eine Tabs zum einrücken benutzt, der andere 2 Leerzeichen und>> der dritte 4 Leerzeichen |-(
Am schlimmsten ist diese völlig kranke Variante, bei der eine
Einrückungsebene mit 4 Leerzeichen gemacht wird und zwei mit einem Tab.
Die ist mir in der Praxis schon öfter begegnet. Das sogt für besonders
schöne Codeformatierung, wenn man selbst mit 4 Leerzeichen arbeitet und
dann halt passend dazu auch die Tab-Weite auf 4 gestellt hat.
> ja, sowas nervt.
Gerade hier sehe ich auch wieder den Vorteil bei Python, wo solche
gemischten Stile halt nicht möglich sind und es daher nicht zu
Kraut-und-Rüben-Einrückung wie in C kommen kann.
> Manche (viele?) unterscheiden zwischen Einrücken und Formatieren. Sie> rücken mit Tabs ein und formatieren mit Leerzeichen.
Wenn man Tabs zur Einrückung verwendet, ist die einzig brauchbare
Variante. Ich kenne allerdings wenig Code, bei dem das auch tatsächlich
konsequent durchgezogen wurde. Das ist auch einer der vielen Gründe,
warum ich auf Tab ganz verzichte.
Sven B. schrieb:> Der TO ist offensichtlich Python-Anfänger und> würde sich bestimmt auch selbst so bezeichnen.
Mei, was heißt Anfänger.
Ich benutze es seit ca. 1 1/2 Jahren, aber unregelmäsig.
Jedesmal wenn ich bei meinen eigentlichen Projekten an eine Stelle komme
wo ich mir denke dass mir ein kleines Skript oder Tool die Arbeit
erleichtern könnte (Codegenerierung, Automatisierung von wiederkehrenden
Aufgaben) hole ich den Python Interpreter raus.
Ich bin jedesmal erstaunt wie einfach und mit wie wenig Code ich meine
Ideen umsetzen kann.
Von dem her bin ich eigentlich zufrieden.
Aber dieser Einrückungszwang (doch, ich bleibe bei der Bezeichnung
"Zwang") stört mich jedesmal aufs neue.
Diesesmal ganz extrem weswegen ich mich hier auch ausgekotzt habe.
Im Großen und Ganzen ist das Problem aber nicht lästig genug um für mich
eine Einarbeitung in Ruby zu rechtfertigen. Mal sehen, vielleicht in nem
Viertel Jahr wenn ich wieder am ausrasten bin :-)
Dass sich die Sprache nicht ändern wird wissen wir alle und will ja auch
keiner.
Für mich ist interessant dass das anscheinend ein sehr emotionales Thema
ist. Ich stehe also mit meiner Meinung nicht alleine da.
Den Rest der sich hier seit gestern Nachmittag getan hat will ich hier
nicht weiter kommentieren.
Der Thread entwickelt sich langsam ja in die übliche "meine
Programmiersprache vs deine Programmiersprache, mein Editor vs dein
Editor, rosa Brille" Richtung.
Lediglich eines will ich noch herauspicken:
> if (a)> { bla;> blubb;> }
Diese Art der Darstellung findet man eigentlich nirgends, und das aus
gutem Grund. Sie ist potthässlich und unleserlich. Dann noch eher K&R
Stil :-)
bal schrieb:> Sven B. schrieb:>> Der TO ist offensichtlich Python-Anfänger und>> würde sich bestimmt auch selbst so bezeichnen.>> Mei, was heißt Anfänger.> Ich benutze es seit ca. 1 1/2 Jahren, aber unregelmäsig.> Jedesmal wenn ich bei meinen eigentlichen Projekten an eine Stelle komme> wo ich mir denke dass mir ein kleines Skript oder Tool die Arbeit> erleichtern könnte (Codegenerierung, Automatisierung von wiederkehrenden> Aufgaben) hole ich den Python Interpreter raus.
Ok, ich hoffe du fasst das nicht als Angriff auf, es war nicht böse
gemeint.
> Aber dieser Einrückungszwang (doch, ich bleibe bei der Bezeichnung> "Zwang") stört mich jedesmal aufs neue.
Verständlich (geht mir zwar nicht so, ist aber verständlich). Aber wie
gesagt, evtl. liegt das einfach nur an deinem falsch konfigurierten
Editor.
> Für mich ist interessant dass das anscheinend ein sehr emotionales Thema> ist. Ich stehe also mit meiner Meinung nicht alleine da.
Wie jedes Thema, was in diesem Forum diskutiert wird ;D
Sven B. schrieb:> Es gibt also eine Methode, die von jedem beliebigen Objekt mit einer> Länge diese Länge ermittelt, und da die "magischen" Namen in Python alle> __foo__() heißen, heißt die halt __len__().
Das Konzept der „magischen Namen“ überzeugt mich dabei nicht. Wenn
ich „help(str)“ frage, dann gibt es ganz offensichtlich auch genügend
„unmagische Namen“, die so ein String-Objekt alle als Methoden hat.
Da hätte man etwas so essenzielles wie dessen Länge weißgott auch so
implementieren können.
> Strings vs. Bytes!
Ich habe nie behauptet, sämtliche Designänderungen in Python 3
schlecht zu finden. Selbst mit print() als Funktion hätte ich
durchaus Verständnis, wenngleich ich den Zeitpunkt von dessen
Einführung für reichlich zu spät halte: wenn ich den Gewinn gegen
den Aufwand (Änderung alter Quellen) stelle, dann wäre es meiner
Meinung nach durchaus sinnvoll gewesen, die Anomalie von print als
Nicht-Funktion beizubehalten. Es hatte sich eh' jeder dran gewöhnt.
Aber andere Änderungen finde ich nicht sinnvoll, beispielsweise
den Wegfall von execfile(), für das ich mir dann umständliche
Konstrukte wie
1
with open(fname) as f:
2
code = compile(f.read(), fname, 'exec')
3
eval(code)
erstmal ergugeln muss.
Sven B. schrieb:> Ich habe für diese Meinung Verständnis, verstehe aber nicht, warum diese> Design-Entscheidung so relevant ist.
Ist sie auch nicht, sie ist nur einfach gelegentlich ärgerlich.
Um nicht mehr und nicht weniger geht dieser Thread auch, schließlich
schrieb der TE gleich zu Anfang:
bal schrieb:> So, genug ausgekotzt.
Jörg Wunsch schrieb:> Sven B. schrieb:>> Es gibt also eine Methode, die von jedem beliebigen Objekt mit einer>> Länge diese Länge ermittelt, und da die "magischen" Namen in Python alle>> __foo__() heißen, heißt die halt __len__().>> Das Konzept der „magischen Namen“ überzeugt mich dabei nicht. Wenn> ich „help(str)“ frage, dann gibt es ganz offensichtlich auch genügend> „unmagische Namen“, die so ein String-Objekt alle als Methoden hat.
Ja, aber das war nicht der Punkt. Der Punkt war, dass die magischen
Namen Konzepte sind, die auch andere Typen haben. Und "capitalize"
gehört da nicht dazu, "len" oder "contains" hingegen schon. Alle
Konzepte die mehrere der grundlegenden Typen in Python haben sind so
implementiert und werden dem Benutzer dann auf andere Art als mit einer
Member-Funktion präsentiert.
> Da hätte man etwas so essenzielles wie dessen Länge weißgott auch so> implementieren können.
Ist ja auch so implementiert, heißt __len__(). len(x) ruft einfach nur
x.__len__() auf.
Ich finde das gut, es gibt eine klare Festlegung von "dies ist ein
Objekt, welches eine Länge hat", und eine klar definierte Art, wie man
darauf zugreift, nämlich mit len(x).
> Aber andere Änderungen finde ich nicht sinnvoll, beispielsweise> den Wegfall von execfile(), für das ich mir dann umständliche> Konstrukte wie
Das läuft jetzt Gefahr, weit vom Thema wegzukommen, aber: wann bitte
braucht man das?
Diese "Regeln", wann die Funktion eine gewöhnliche und wann eine
Memberfunktion ist, kann ich auch nicht ganz nachvollziehen.
Da muss ich jetzt auch mal meckern und gebe Jörg recht :)
Auch die Stellungnahme von Guido hilft mir nicht arg weiter:
https://mail.python.org/pipermail/python-3000/2006-November/004643.htmlSven B. schrieb:> Ja, aber das war nicht der Punkt. Der Punkt war, dass die magischen> Namen Konzepte sind, die auch andere Typen haben. Und "capitalize"> gehört da nicht dazu, "len" oder "contains" hingegen schon.
Was ist bspw. mit index? Das ist eine Funktion, die alle geordneten
Containertypen haben, Wieso ist sie nicht (ähnlich wie len) als
freistehende Funktion definiert?
Guido schreibt, dass len(x) besser als x.len() lesbar ist. Ok,
einverstanden. Aber wie sieht es mit join aus? Um die Strings s1, s2,
s3 miteinander zu verketten, muss man schreiben
Yalu X. schrieb:> Wieso nicht> s = join([s1, s2, s3])
Weil join keine allgemeine Sache ist und nur für Strings (oder
vielleicht noch einige andere iterables) einen Sinn ergibt.
Yalu X. schrieb:> Was ist bspw. mit index? Das ist eine Funktion, die alle geordneten> Containertypen haben, Wieso ist sie nicht (ähnlich wie len) als> freistehende Funktion definiert?
Weil das, genauso wie __contains__(), eine eigene Syntax hat, nämlich
x[a] (bzw. das ist die Notation für __getitem__(), __index__() ist eine
Variante davon).
> Guido schreibt, dass len(x) besser als x.len() lesbar ist. Ok,> einverstanden. Aber wie sieht es mit join aus? Um die Strings s1, s2,> s3 miteinander zu verketten, muss man schreiben
Das join ist Mist, darauf können wir uns gern einigen ;)
Sven B. schrieb:> (bzw. das ist die Notation für __getitem__(), __index__() ist eine> Variante davon)
Ich meinte nicht __getitem__ oder __index__, sondern tatsächlich
index, also die Suchmethode, die es bspw. in Listen, Tuples, Strings,
Ranges usw. gibt.
Yalu X. schrieb:> Ich meinte nicht __getitem__ oder __index__, sondern tatsächlich> index, also die Suchmethode, die es bspw. in Listen, Tuples, Strings,> Ranges usw. gibt.
Ok, das stimmt, das wäre konsistenter das auch in der anderen Notation
zu machen.
bal schrieb:>> if (a)>> { bla;>> blubb;>> }>> Diese Art der Darstellung findet man eigentlich nirgends, und das aus> gutem Grund. Sie ist potthässlich und unleserlich. Dann noch eher K&R> Stil :-)
völliges Unverständnis meinerseits. Es ist eine sowohl platzsparende als
auch sehr übersichtliche Scheibweise. Was zum Teufel findest du daran
häßlich oder an K&R schöner? Daß man bei K&R erstmal irgendwo hinten auf
den Zeilen nach dem zugehörigen Blockanfang suchen muß? oder daß man
einsame Klammern auf jeweils einer Zeile hat? Nee, nicht mein Ding! Ieks
bäh. Jetzt könnte ich ja noch ganz anders:
if a
then begin
bla;
blubb
end;
gelle? Also ganz generell eines: Mit dedizierten Blockmarkern hat jeder
nach seinem Schreibgefühl die Möglichkeit, seinen Quelltext optimal
grafisch zu gestalten - mit einer festgeschriebenen Einrückregel
hingegen nicht, das ist ein Zwang und von Zwängen solcher Art hat
zumindest unsereiner endgültig die Nase voll. Ich erinnere an
vorgeschriebene Grußformeln in gehabten Diktaturen.
klausro schrieb:> Grad' bei der> letzten Variante stellen sich bei mir die Zehennägel auf. Immer nervig,> fremden Code durch "indent" zu jagen. Aber wenigstens gibt es so ein> Tool.
wahrscheinlich würde ich dich windelweich prügeln, wenn du sowas mit
MEINEM Code machen würdest.. Aber genau HIER sehen wir, was es für ein
Fehlgriff in einem Sprachentwurf ist, Einrückungen zum syntaktischen
Element zu machen. Deine Vorstellungen über Ästhetik und Lesbarkeit
haben offenbar mit den meinigen ein verschwindendes Skalarprodukt.
Yalu X. schrieb:> Hier ist ein kleines Beispiel, einmal mit Braces und einmal klassisch:
O ha, Yalu, hier wirst du aber ziemlich tendenziell, sprich bösartig.
Schreib mal das ganze in dem von mir angegebenen Stil (also die öffnende
Klammer nicht auf einsamer Zeile) und du wirst sehen, daß es plötzlich
richtig GUT und leserlich aussieht.
Mir kommt das langsam vor wie die Diskussionen um 'goto'...
ach, gut Nacht, Leute!
W.S.
W.S. schrieb:> völliges Unverständnis meinerseits. Es ist eine sowohl platzsparende als> auch sehr übersichtliche Scheibweise.
Ist halt Ansichts- und vor allem Gewohnheitssache. Dieser Stil ist nicht
besonders verbreitet und ich finde den (vielleicht deshalb?) auch
hässlich.
> Aber genau HIER sehen wir, was es für ein> Fehlgriff in einem Sprachentwurf ist, Einrückungen zum syntaktischen> Element zu machen.
Ne, genau hier sieht man, was das für 'ne gute Idee ist. Dann sieht
nämlich der Code aller gleich aus, statt dass jeder Idiot für jede
Funktion seinen eigenen Formatierungsstil erfindet, wie das zum Beispiel
bei so gut wie jedem größeren C++-Projekt der Fall ist.
W.S. schrieb:> Daß man bei K&R erstmal irgendwo hinten auf> den Zeilen nach dem zugehörigen Blockanfang suchen muß?
Jeden Tag verbringe ich bis zu 8 Stunden mit C Quelltext. Alles im
K+R-Stil. NOCH NIE habe ich nach "zugehörigem Blockanfang" suchen
müssen, denn mein C-Code ist zusätzlich zu den {} auch ordentlich
eingerückt und ich halte meine Einrückung stets und ständig synchron mit
der Klammerebene und zwar mit einer geradezu religiös-rituellen
Penibilität.
Auch alle anderen die jemals daran [an besagtem Code] arbeite(te)n
halten es ebenso.
Ich weiß nicht was Du so treibst oder wie chaotisch obfuskiert Dein Code
aussieht daß Du ständig nach Klammern suchen musst, ich persönlich kann
nicht nachvollziehen warum jemand mehr als 0.001% seiner Zeit mit so
einer deprimierenden Tätigkeit verbringen sollte. Das kann bestenfalls
einmal vorkommen wenn man einen fremden Codeschnipsel der so absurd
formatiert ist wie der Code in Deinem Beispiel ein und für allemal auf
ordentliches K+R umformatiert und danach nie wieder. Danach ist jeder
Blockanfang auch aus 5 Metern Entfernung deutlich an der Einrückung
erkenntlich, dann könnte man die Klammern auch weglassen und sich die
unsägliche AltGr-Fingerverrenkung¹ sparen wenn C das erlauben würde.
Python geht hier konsequent den nächsten (sich logisch aufdrängenden)
Schritt und wirft diesen unnötigen redundanten Klammerballast kurzerhand
über Bord.
Und das ist gut so.
_______
¹ aus diesem Grunde (unter vielen anderen) bevorzuge ich übrigens auch
jederzeit Pascal über C++ weil mir ein "begin" flüssiger und schneller
aus der Hand fließt als ein sehnenscheidenmordendes "AltGr + 7".
Moin Moin,
Bernd K. schrieb:>> erkenntlich, dann könnte man die Klammern auch weglassen und sich die> unsägliche AltGr-Fingerverrenkung¹ sparen wenn C das erlauben würde.
deshalb bevorzuge ich Appletastaturen mit US-Layout. Auf der
deutschen sind solche Zeichen wie | {} [] \ ~ nämlich erst gar
nicht drauf :)
Micha
Bernd K. schrieb:> Ich weiß nicht was Du so treibst oder wie chaotisch obfuskiert Dein Code> aussieht daß Du ständig nach Klammern suchen musst..
Das muß ich nur in Quellen, die nicht von mir stammen. In meinem Zeugs
geht es ordentlich zu.
Nun, im Gegensatz zu Zeitgenossen, die eben bloß sowas wie "potthäßlich"
daherreden können, habe ich für meine bevorzugten Quellstil eine
sachliche Begründung:
Die Block-Kennzeichner gehören in die gleiche Spalte, damit man sie
möglichst leicht zuordnen kann. Bei K&R geht das nicht, dort müßte man
zwei unterschiedliche Dinge optisch in Relation setzen: die erste
Anweisung innerhalb des Blockes und den Blockende-Kennzeichner. Das sind
aber zwei Dinge unterschiedlicher Klasse und das ist schlecht.
Der Innenbereich des Blockes soll eingerückt sein, um ihn optisch von
den Block-kennzeichnern und dem Bereich außerhalb des Blockes zu
unterscheiden.
Innerhalb des Block-Innenbereiches können durchaus weitere Einrückungen
nötig sein, um z.B. Besonderheiten darzustellen, die außerhalb der
Sprachdefinition liegen. Beispiel: spezielle Unlock-Sequenzen für
HW-Funktionalitäten, die eben GENAU SO sein müssen, ohne daß man das aus
Kenntnis der Programmiersprache ersehen könnte.
Bei Pascal ist die Sache gegessen, dort ist
if a
then begin
blabla...
...
end
oder wenn's breiter wird
if a
then
begin
blabla..
...
end
einfach üblich und es gibt nur wenige Leute, die es wesentlich anders
halten.
Bei C is aus oben genanntem Grund K&R schlecht, weswegen nur
if (a)
{
blabla
...
}
oder eben
if (a)
{ blabla
...
}
und ne Variante
if (a)
{ // warumnur weshalbdas
blabla
...
}
verbleiben. So richtig interessant wird das, wenn die Kondition(en)
recht umgänglich werden, was man sehr häufig in vielen Quellen sieht.
Also etwa so:
if ((viusaisak!=hfhvkjfvs<>ieurisfksl|dkklkcsdcds) ||
(lalalalalasjdfhsjfhf*/2i3rikakf>slkjfjsgkkg) ||
(llkjkjfdgkdvkddl.....f.g.dfds..d..f.gfhg.ga))
{ // warumdarumlaberbla
blabla
...
}
else
{ // sonsthebenwiedeshiergelle
lalalala
...
}
Ja, so geht's.
Bernd K. schrieb:> Python geht hier konsequent den nächsten (sich logisch aufdrängenden)> Schritt und wirft diesen unnötigen redundanten Klammerballast kurzerhand> über Bord.>> Und das ist gut so.
Und das ist schlecht so.
Warum?
Weil dieser Klammerballast eben kein Ballast ist, sondern ein
notwendiges Mittel zur Strukturierung von Programmen. Und er ist nicht
über Bord geworfen, sondern bloß gegen eine wesentlich undurchsichtigere
Regel ersetzt, nämlich die mit dem syntaktischen Einrücken. Das Bilden
von Blöcken ist IMMER notwendig und sollte mit möglichst einsichtigen
Mitteln bewerkstelligt werden. Bei Pascal ist das ideal gelöst, denn
'begin' und 'end' versteht quer über den Erdball wirklich jeder - die
Bedeutung von unterschiedlichen Klammern hingegen nicht. Deine Kritik an
der Sonderzeichen-Manie bei C kann ich somit verstehen, aber wir
diskutieren hier ja eigentlich Python, oder?
Sven B. schrieb:> Ne, genau hier sieht man, was das für 'ne gute Idee ist. Dann sieht> nämlich der Code aller gleich aus, statt dass jeder Idiot für jede> Funktion seinen eigenen Formatierungsstil erfindet, wie das zum Beispiel> bei so gut wie jedem größeren C++-Projekt der Fall ist.
Du bevorzugst den Zwang? oder Gleichschaltung? Ich nicht. Ich hätte SEHR
was dagagen, in ein FDJ-Hemd gesteckt zu werden und von Popanzen zum
Gleichschritt in eine von Bonzen vorgegebene Richtung getrieben zu
werden.
Einen vernünftigen, auf eigenen sinnvollen Erwägungen beruhenden
Schreibstil zu haben, finde ich hingegen gut - einschließlich der
Möglichkeit, selbigen gelegentlich zu verlassen, wenn anderweitige
Gründe mir das sinnvoll erscheinen lassen.
Wenn andere von dir genannte C++ Programmierer (Zitat "jeder Idiot")
hingegen einen chaotischen Stil schreiben, dann liegt es an deren
schlechter geistiger Verfassung - wenn sie denn vernünftig schreiben
WOLLTEN, dann KÖNNTEN sie das auch. Mich kotzen hingegen ganz andere
Dinge an. Häufigstes Beispiel: in jeder Quelle die GPL in vollem
Wortlaut zitiert, aber keinerlei Info über Sinn und Zweck und
Zugehörigkeit der betreffenden Quelle, ebenao auch keinerlei
aussagekräftige Bezeichner. Das ist viel ätzender.
W.S.
W.S. schrieb:> Weil dieser Klammerballast eben kein Ballast ist, sondern ein> notwendiges Mittel zur Strukturierung von Programmen. Und er ist nicht> über Bord geworfen, sondern bloß gegen eine *wesentlich undurchsichtigere*> Regel ersetzt, nämlich die mit dem syntaktischen Einrücken.
Das ist Deine Meinung. Meine Ansicht jedoch welche auf tatsächlicher
Erfahrung gründet und nicht nur auf Meinungsbildung mittels Vermutung
(und da geh ich konform mit allen anderen Python Programmierern) ist daß
die Einrückung als Kennzeichnung mindestens genauso durchsichtig ist wie
die Klammersetzung.
Da man übersichtlichen Code ohnehin einrücken muss (egal welche Sprache)
kann man nach erfolgter Einrückung die nunmehr überflüssig gewordenen
Klammern auch einfach komplett weglassen, sie transportieren dann keine
Information mehr sie erzeugen nur noch unerwünschtes syntaktisches
Rauschen.
> Sven B. schrieb:>> Ne, genau hier sieht man, was das für 'ne gute Idee ist. Dann sieht>> nämlich der Code aller gleich aus, statt dass jeder Idiot für jede>> Funktion seinen eigenen Formatierungsstil erfindet, wie das zum Beispiel>> bei so gut wie jedem größeren C++-Projekt der Fall ist.>> Du bevorzugst den Zwang? oder Gleichschaltung? Ich nicht. Ich hätte SEHR> was dagagen, in ein FDJ-Hemd gesteckt zu werden und von Popanzen zum> Gleichschritt in eine von Bonzen vorgegebene Richtung getrieben zu> werden.https://de.wikipedia.org/wiki/Godwin%E2%80%99s_law
</thread>
> Häufigstes Beispiel: in jeder Quelle die GPL in vollem> Wortlaut zitiert, aber keinerlei Info über Sinn und Zweck und> Zugehörigkeit der betreffenden Quelle, ebenao auch keinerlei> aussagekräftige Bezeichner.
Wenn du das nicht machst, schreiben dir die Debian-Packager böse Mails.
Absätze über den Zweck der Datei interessieren die hingegen gar nicht.
Sven B. schrieb:>> Sven B. schrieb:>>> Ne, genau hier sieht man, was das für 'ne gute Idee ist. Dann sieht>>> nämlich der Code aller gleich aus, statt dass jeder Idiot für jede>>> Funktion seinen eigenen Formatierungsstil erfindet, wie das zum Beispiel>>> bei so gut wie jedem größeren C++-Projekt der Fall ist.>>>> Du bevorzugst den Zwang? oder Gleichschaltung? Ich nicht. Ich hätte SEHR>> was dagagen, in ein FDJ-Hemd gesteckt zu werden und von Popanzen zum>> Gleichschritt in eine von Bonzen vorgegebene Richtung getrieben zu>> werden.> https://de.wikipedia.org/wiki/Godwin%E2%80%99s_law
na kommm, weder N.... noch H..... werden hier genannt.
> </thread>>>> Häufigstes Beispiel: in jeder Quelle die GPL in vollem>> Wortlaut zitiert, aber keinerlei Info über Sinn und Zweck und>> Zugehörigkeit der betreffenden Quelle, ebenao auch keinerlei>> aussagekräftige Bezeichner.> Wenn du das nicht machst, schreiben dir die Debian-Packager böse Mails.> Absätze über den Zweck der Datei interessieren die hingegen gar nicht.
ohne es jetzt genau zu wissen, du musst tatsächlich in jeder
Quelltextdatei von Debian und sei sie noch so klein, den kompletten Text
der GPL drin haben?
Du meinst doch eher den Teil der unter "How to Apply These Terms to Your
New Programs" aufgeführt ist, oder?
Micha
Micha S. schrieb:> ohne es jetzt genau zu wissen, du musst tatsächlich in jeder> Quelltextdatei von Debian und sei sie noch so klein, den kompletten Text> der GPL drin haben?
Ach so, ne, natürlich nicht, nur diesen Kopf. Den vollen Text macht aber
auch niemand, das habe ich noch nie gesehen.
W.S. schrieb:> Die Block-Kennzeichner gehören in die gleiche Spalte, damit man sie> möglichst leicht zuordnen kann.
Wenn man von der Block-Ende-Klammer rückwärts sucht, sucht man für
gewöhnlich nicht den Blockanfang an sich, sondern die Kopfzeile der
While-Anweisung¹, zu der der Block gehört. Deswegen sollte meiner
Meinung nach die Block-Ende-Klammer in der gleichen Spalte wie das
Schlüsselwort "while" stehen. Damit die Suche geradlinig und ohne
Unterbrechung erfolgen kann, sollte in dieser Spalte zwischen dem "if"
und der schließenden Block-Ende-Klammer nur Leerraum stehen (s. Beispiel
1 im Anhang).
Steht die Block-Anfang-Klammer in einer eigenen Zeile oder direkt vor
der ersten Anweisung innerhalb des Blocks, trifft man bei der
Rückwärtssuche erst einmal auf den (wenig interessierenden) Blockanfang.
Um zu entscheiden, ob eine darüberliegendes "while" der Kopf dieses
Blocks ist, musst man erst das Ende der While-Zeile untersuchen
(Beispiel 2), denn es könnte sich ja auch um eine in sich abgeschlossene
Schleife handeln, die mit dem Block nichts zu tun hat (Beispiel 3).
Die Block-Anfang-Klammer direkt vor die ersten Anweisung innerhalb des
Blocks zu schreiben, hat auch den Nachteil, dass man beim Kopieren von
zusätzlichen Zeilen an den Blockanfang vorher dessen ersten Zeile
umgebrechen und nach dem Einfügen der neuen Zeilen wieder zusammenfügen
muss.
————————————
¹) Das Geschriebene gilt sinngemäß natürlich auch für If-, Do-, For- und
Switch-Anweisungen.
Yalu X. schrieb:> Um zu entscheiden, ob eine darüberliegendes "while" der Kopf dieses> Blocks ist, musst man erst das Ende der While-Zeile untersuchen> (Beispiel 2), denn es könnte sich ja auch um eine in sich abgeschlossene> Schleife handeln, die mit dem Block nichts zu tun hat (Beispiel 3).
wobei ich bei solchen Konstruktionen auf jeden Fall eine Leerzeile
zwischen alleinstehendem Block und der Nur-Kopf-Schleife lassen würde.
Yalu X. schrieb:> ¹) Das Geschriebene gilt sinngemäß natürlich auch für If-, Do-, For- und> Switch-Anweisungen.
..und NICHT für 'else' ?
oder für Blöcke, die aus anderen Gründen eben Blöcke sind (z.B. wegen
lokaler Variablen usw.)? Bedenke, daß es garantiert niemandem auf dieser
Welt möglich ist, wirklich ALLE auftreten könnenden Gründe anderer Leute
vorab berücksichtigen zu können.
Bernd K. schrieb:> Das ist Deine Meinung. Meine Ansicht jedoch welche auf tatsächlicher> Erfahrung gründet und..
nein, das ist keine Meinung sondern eine Feststellung.
In wohl fast JEDER Programmiersprache - und in ALLEN imperativen
Programmiersprachen braucht es die Möglichkeit zur Blockbildung. Das ist
ein Fakt,
Also braucht es Kennzeichner, die den Blockbeginn und dessen Ende
kennzeichnen. Das ist ebenfalls ein Fakt. man kann dies nun durch
lesbare Dinge wie eben {} oder begin end machen oder eben durch nicht
lesbare Dinge wie hier eben, wo man im Prinzip die 1. Ableitung aus der
Anzahl der führenden Leerzeichen bilden müßte. Ist sie >0 dann ist das
ein Blockanfang, ist sie <0 dann ein Blockende, ist sie 0 dann sind wir
mitten drin. Und was ist mit Kommentaren oder Einrückungen aus
anderweitigen Gründen? und mit Leezeilen? und mit Tabulatoren? Das sind
alles Sonderkonditionen bei solcher Sprachdefinition, die schlichtweh
NICHT lesbar und deshalb nicht offensichtlich sind, sondern gelernt
(gepaukt) werden müssen.
So, ehe wir uns hier weiter um des Kaisers Bart streiten, stelle ich
fest (censeo), daß man mit solchen Konstrukten wie Python nach
ausreichender Einarbeitung eben auch zurecht kommen kann - was im
Prinzip auch für die beknackteste Programmiersprache gilt - aber daß die
Blockbildung per Einrückung eine ausgesprochen schlechte Idee ist.
Damit soll's zumindest für mich genug sein, nächstes Jahr gibt es
garantiert die nächsten 3 neuen Programmiersprachen, selbstveständlich
noch viel besser als alles bis da Gewesene.
W.S.
Bernd K. schrieb:> Die Einrückungssyntax von Python wird regelmäßig nur von Leuten> kritisiert die noch nie ernsthaft mit Python gearbeitet haben und sich> daher nur realitätsferne Szenarien ausdenken können (wie zum Beispiel> der Kollege weiter oben dem über Nacht immer die Heinzelmännchen> heimlich den Code "zerreißen").
Wer solche Freunde hat ...
Wirft für mich jedenfalls kein gutes Licht auf die Verfechter, wenn sie
der Reihe nach dadurch auffallen, daß sie geschilderte Probleme
lächerlich machen oder schlicht nicht wahrhaben wollen.
Michael schrieb:> daß sie geschilderte Probleme> lächerlich machen oder schlicht nicht wahrhaben wollen.
Das ist aber kein "geschildertes Problem" sondern reine Fantasie. Es
gibt nämlich überhaupt keine Heinzelmännchen.
W.S. schrieb:> oder eben durch nicht> lesbare Dinge wie hier eben
Unfug. Einrückungen sind besser lesbar als geschweifte Klammern und im
Gegensatz zu selbigen noch aus 5 Metern Entfernung deutlich zu erkennen.
W.S. schrieb:> Also braucht es Kennzeichner, die den Blockbeginn und dessen Ende> kennzeichnen. Das ist ebenfalls ein Fakt. man kann dies nun durch> lesbare Dinge wie eben {} oder begin end machen oder eben durch nicht> lesbare Dinge wie hier eben, wo man im Prinzip die 1. Ableitung aus der> Anzahl der führenden Leerzeichen bilden müßte. Ist sie >0 dann ist das> ein Blockanfang, ist sie <0 dann ein Blockende, ist sie 0 dann sind wir> mitten drin.
Wow, das muß man erstmal hinkriegen, so etwas einfaches auf so
komplizierte Weise zu beschreiben.
Man könnte jetzt dagegen halten, daß man bei {} die Ebene des Blocks
erst durch Integration der Klammern rausbekommt, wobei eine öffnende
Klammer der 1 und eine schließende der -1 entspricht. Keine Klammer ist
dann die 0. So kann man auch ganz einfach vergessene Klammern erkennen:
Wenn das Integral irgendwo < 0 wird oder am Ende der Datei > 0 ist,
stimmt was nicht.
> Und was ist mit Kommentaren oder Einrückungen aus anderweitigen Gründen?> und mit Leezeilen? und mit Tabulatoren?
Was soll damit sein?
> Das sind alles Sonderkonditionen bei solcher Sprachdefinition, die> schlichtweh NICHT lesbar und deshalb nicht offensichtlich sind, sondern> gelernt (gepaukt) werden müssen.
Wer schon vor solchen Lernaufgaben zurückschreckt, sollte vielleicht das
Programmieren gleich sein lassen.
Das gilt übrigens in C++ auch z.B. für die Regeln, die festlegen, nach
welchen schließenden Klammern ein Semikolon stehen muß, wo eins stehen
darf und wo auf keinen Fall eins sein darf.
> Damit soll's zumindest für mich genug sein, nächstes Jahr gibt es> garantiert die nächsten 3 neuen Programmiersprachen, selbstveständlich> noch viel besser als alles bis da Gewesene.
Die gibt es vor allem deshalb, weil irgendwer sich immer an
irgendwelchen Details stört und deshalb glaubt, die ultimative Sprache
basteln zu müssen - an deren Eigenheiten sich dann der nächste stört,
u.s.w.
Bernd K. (prof7bit) schrieb:
> Unfug. Einrückungen sind besser lesbar als geschweifte Klammern und im> Gegensatz zu selbigen noch aus 5 Metern Entfernung deutlich zu erkennen.
Es wird immer absurder hier sich die Zwangseinrückungen mit absurden
Kommentaren schön zu reden. Erst wird behauptet, das es den Code dadurch
"deutlich kompakter macht", als ob wir heutzutage noch alle auf einem
futzelkleinen EGA Monitor unter DOS rumhacken würden und unter
Zeilenarmut zu leiden hätten. Nun wird als Pro-Einrück-Argument
angeführt, man könne damit den Code schon aus "5 Meter Entfernung
deutlich erkennen". Das tut ja schon weh, was man hier so alles lesen
muss. Das sind Nichtargumente. Lasst euch mal was besseres einfallen.
Mein Eindruck ist zunehmend, W.S. (Gast) hat mit dem was er dazu
schreibt recht:
" Und das ist schlecht so.
Warum?
Weil dieser Klammerballast eben kein Ballast ist, sondern ein
notwendiges Mittel zur Strukturierung von Programmen. Und er ist nicht
über Bord geworfen, sondern bloß gegen eine wesentlich
undurchsichtigere
Regel ersetzt, nämlich die mit dem syntaktischen Einrücken. Das Bilden
von Blöcken ist IMMER notwendig und sollte mit möglichst einsichtigen
Mitteln bewerkstelligt werden. Bei Pascal ist das ideal gelöst, denn
'begin' und 'end' versteht quer über den Erdball wirklich jeder - die
Bedeutung von unterschiedlichen Klammern hingegen nicht. Deine Kritik
an
der Sonderzeichen-Manie bei C kann ich somit verstehen, aber wir
diskutieren hier ja eigentlich Python, oder? "
Bernd K. schrieb:> Unfug. Einrückungen sind besser lesbar als geschweifte Klammern und im> Gegensatz zu selbigen noch aus 5 Metern Entfernung deutlich zu erkennen.
Die meisten Ehen sind alles andere als perfekt.
Objektiv betrachtet waere eine Scheidung schon laengst überfaellig.
Und trozdem überdauern solche Ehen Jahrzehnte. Und meist: bis der Tod
Euch scheide.
Gewohnheit. Man hat sich aneinander gewöhnt. Die Macken des Partners zu
ertragen faellt einem einfacher, als den Scheidungsweg zu begehen.
Ebenso ist es bei mir mit den Klammern. Ich vermisse sie, wenn ich mit
Python programmiere. Ein objektives Argument habe ich keine für die
Klammern. Aber wenn es eine Option gaebe, die nebst dem obligaten
Einrücken auch das (zusaetzliche) Setzen von Klammern erlauben würde:
also ich taete sie benützen und würde mich viel wohler fühlen.
Rolf Magnus (Gast) schrieb:
> Die gibt es vor allem deshalb, weil irgendwer sich immer an> irgendwelchen Details stört und deshalb glaubt, die ultimative Sprache> basteln zu müssen - an deren Eigenheiten sich dann der nächste stört,> u.s.w.
Genau das trifft doch auf Python zu. Oder was hat denn den
Python-Entwickler an den typischen C-Klammern gestört?
Erkläre mir bitte mal, wenn das Weglassen von Klammern so toll ist,
warum wird das dann nicht künftig auch bei C/C++ so gemacht? Damit
müsste C/C++ doch eigentlich signifikant attraktiver werden oder etwa
doch nicht?
unechter Python-Programmierer schrieb:> Weil dieser Klammerballast eben kein Ballast ist, sondern ein> notwendiges Mittel zur Strukturierung von Programmen.
Offensichtlich nicht notwendig, siehe zum Beispiel Python. Da geht es
mit Einrückungen statt Klammern ganz wunderprächtig und vollkommen
problemlos (Ja, richtig gelesen: problemlos, ob Du es glaubst oder
nicht!)
Bernd K. (prof7bit) schrieb:
unechter Python-Programmierer schrieb:
>> Weil dieser Klammerballast eben kein Ballast ist, sondern ein>> notwendiges Mittel zur Strukturierung von Programmen.> Offensichtlich nicht notwendig, siehe zum Beispiel Python. Da geht es> mit Einrückungen statt Klammern ganz wunderprächtig und vollkommen> problemlos (Ja, richtig gelesen: problemlos, ob Du es glaubst oder> nicht!)
Sag mal liest du eigentlich auch mal das, was andere dazu bereits
vielfach schrieben? Worüber reden wir hier eigentlich die ganze Zeit?
"Zufälligerweise" über Einrückungen bei .. na was wohl .. PYTHON!!
Dann kommst du und schreibst sinngemäß als Antwort "habe hier EIN
Beispiel für Klammerfreiheit, nennt sich Python".
Das das geht bezweifelt keiner. Ob das der Königsweg ist oder eher
nachteilig, darum geht es doch die ganze Zeit.
unechter Python-Programmierer schrieb:> Es wird immer absurder hier sich die Zwangseinrückungen mit absurden> Kommentaren schön zu reden.
Die Gegenseite kommt mit nicht minder absurden Kommentaren daher, oder
willst du behaupten, die Abhandlung von W.S. zum Thema Ableitung von
Einrückungsebenen sei nicht absurd?
unechter Python-Programmierer schrieb:>> Die gibt es vor allem deshalb, weil irgendwer sich immer an>> irgendwelchen Details stört und deshalb glaubt, die ultimative Sprache>> basteln zu müssen - an deren Eigenheiten sich dann der nächste stört,>> u.s.w.>> Genau das trifft doch auf Python zu. Oder was hat denn den> Python-Entwickler an den typischen C-Klammern gestört?
Vermutlich hat er sie für unnötig gehalten, wie es andere hier auch tun.
Und siehe da, es geht tatsächlich auch ohne.
> Erkläre mir bitte mal, wenn das Weglassen von Klammern so toll ist,> warum wird das dann nicht künftig auch bei C/C++ so gemacht?
Ich habe mit den Klammern eigentlich kein wirkliches Problem. Sie sind
halt Teil der Sprache. Ich habe aber ganz genausowenig ein Problem
damit, daß es in Python diese Klammern nicht gibt. Und was ich "so toll"
daran finde, habe ich weiter oben schon erklärt.
> Damit müsste C/C++ doch eigentlich signifikant attraktiver werden oder> etwa doch nicht?
Das wäre sie schon alleine aufgrund dessen, daß es sich ändert, nicht.
Umgekehrt würde sich aber heute vermutlich keiner über Python aufregen,
wenn C gleich ohne die Klammern erfunden worden wäre. Dann würde man das
als ganz normal betrachten.
Also in C kann ich innerhalb eine Blockes ohne Probleme Sub-Blöcke
bilden, was manchmal recht praktisch sein kann, besonders wenn man eine
längere, schlecht teilbare Funktion hat und man lokal begrenzte
Variablen definieren möchte (zb, weil man mit einer C version arbeiten
muss, die Deklarationen nur am Blockanfang zulässt).
unechter Python-Programmierer schrieb:> Das das geht bezweifelt keiner. Ob das der Königsweg ist oder eher> nachteilig, darum geht es doch die ganze Zeit.
Ich verstehe diesen Glaubenskrieg hier absolut nicht mehr...
In C/C++ werden Klammer als "Blockmarker" benutzt, und der Code wird
trotzdem eingerückt, auch wenn es nur der Lesbarkeit dient.
Warum also nicht die Klammern weglassen und nur die Einrückung als
Blockmarker nutzen? Wo ist das Problem?
Ob ich nun in C/C++ schreibe:
1
while(bedingung)
2
{
3
foo();
4
}
5
// weiterer code
oder wie auch immer ihr das formatieren wollt, es nimmt sich absolut
nicht zu Python:
1
while(bedinung):
2
foo()
3
# weiterer code
Es ist beides eingerückt! Wird sich da jetzt dran gestört das die
Klammern fehlen? Das ist so, als wenn sich jemand am fehlenden Semikolon
stört... Das ist einfach albern.
"Das sieht anders aus, als das, was ich gewohnt bin, des wegen find ich
das scheiße...", so hört sich das für mich an.
Nochmal zum mitschreiben:
Egal ob C oder Python: Der Code wird eingerückt! Warum also nicht die
Einrückung als "Blockmarker" nutzen? Wenn ich mir C-Code anschaue, dann
ergeben sich Code-Blöcke weniger aus den Klammern, sondern mehr aus der
Einrückung, einfach weil die Einrückung sofort ins augespringt, als
irgendeine Klammer, die stehen kann, wo sie will.
Das Argument
bal schrieb:> Mal eben einen größeren Block durch> ein if-statement schützen? Dauert ewig. Dasselbe gilt für die> for-schleife. Die baut man nicht "mal eben" drum herum.> Umgekehrt natürlich das gleiche.
ist ebenso blödsinn.
In Python muss ich aufpassen das die richtigen Zeilen entsprechend
eingerückt sind. Und? In C/C++ muss ich auch aufpassen das die Klammer
an der richtigen Stelle steht. Wo ist jetzt der große Unterschied an dem
Sich gestört wird?
Ob ich nun in C/C++ aufpassen muss das der Blockmarker(Klammern) an der
richtigen Stelle ist, oder in Python auf den Blockmarker(Einrückung)
aufpassen muss, das ist doch völlig wurst.
W.S. schrieb:> nächstes Jahr gibt es> garantiert die nächsten 3 neuen Programmiersprachen, selbstveständlich> noch viel besser als alles bis da Gewesene.
Dann lass uns mal schauen wann Python rausgekommen ist... 1991! also bei
weitem nicht neu. c++ - 1985, nimmt sich also beides vom Alter her
nichts.
Hier mal ein C/Python Beispiel aus wikipedia:
1
Fakultätsfunktion in C (mit Einrückung):
2
int fakultaet(int x) {
3
if (x > 1) {
4
return x * fakultaet(x - 1);
5
} else {
6
return 1;
7
}
8
}
9
10
Jetzt die gleiche Funktion in Python:
11
def fakultaet(x):
12
if x > 1:
13
return x * fakultaet(x - 1)
14
else:
15
return 1
Im C-Code interessieren die klammern überhaupt nicht, da sich die Blöcke
durch einrückung ergeben, ja, ich finde die Klammern schon fast störend.
Die Klammern bringen absolut keinen Mehrwert in die Angelegenheit. Da es
in diesem Beispiel legitim ist, die klammern wegzulassen, machen wir das
doch mal kurz:
1
int fakultaet(int x) {
2
if (x > 1)
3
return x * fakultaet(x - 1);
4
else
5
return 1;
6
}
7
8
Jetzt die gleiche Funktion in Python:
9
def fakultaet(x):
10
if x > 1:
11
return x * fakultaet(x - 1)
12
else:
13
return 1
Die Hölle muss sofort zu frieren... der C-Code sieht ja genauso aus wie
der Python-Code... ooops, wie konnte das nur passieren? Hier stört sich
kein Schwein an den fehlenden Klammern im C-Code, aber im Python-Code
ist das plötzlich scheiße, unleserliche und ein "no go"? Ernsthaft?
Kommt mal auf euer Leben klar und schaut über den Tellerrand oder sterbt
in eurem Keller, was anderes fällt mir dazu nicht ein!
Ich verstehe diesen ganzen Thread nicht! Ehrlich, ich versteh es nicht!
Das hier hat nichts mit Diskussion zu tun, das ist einfach nur
Kindergarten, nicht mehr, nicht weniger!
Ebenso wie bei Debian über systemd, startup, usw. "diskutiert" wird...
dieser thread hier hat das gleiche Nivea!
Kaj schrieb:> Nochmal zum mitschreiben:> Egal ob C oder Python: Der Code wird eingerückt! Warum also nicht die> Einrückung als "Blockmarker" nutzen?
Weil das zu bösen Effekten führen kann, wenn in einem File Tabs und
Spaces gemischt zur einrückung verwendet werden.
Jemand hat einen neuen Rechner, und den Editor nocht nicht richtig
konfiguriert, modifiziert das Script und checkt es ein.
Der nächste hat das automatische Ersetzen der Tabs durch Spaces
aktiviert. Dummerweise mit einer anderen Breite, als der, der das
zuletzt editiert hat.
Der Fehler fällt nicht auf, weil er in gerade unbenutzten Routinen
liegt. das Skript wird angepasst und eingecheckt.
Der Nächste holt es sich, will es benutzen und es ist kaputt.
Python ist wirklich toll, aber die Sache mit der Einrückung nervt.
Kaj schrieb:> Die Hölle muss sofort zu frieren... der C-Code sieht ja genauso aus wie> der Python-Code
darum geht es doch überhaupt nicht.
Kaj schrieb:> Hier stört sich kein Schwein an den fehlenden Klammern
Doch. die meisten Coding-Rules und Code-Qualitätswerkzeuge erzwingen
diese explizit.
Rolf Magnus (Gast) schrieb:
>> Genau das trifft doch auf Python zu. Oder was hat denn den>> Python-Entwickler an den typischen C-Klammern gestört?> Vermutlich hat er sie für unnötig gehalten, wie es andere hier auch tun.> Und siehe da, es geht tatsächlich auch ohne.
Die Frage ist doch nicht, ob "es geht". Die Frage ist, was gewinnt man
dabei und was büßt man ein!
> Umgekehrt würde sich aber heute vermutlich keiner über Python aufregen,> wenn C gleich ohne die Klammern erfunden worden wäre. Dann würde man das> als ganz normal betrachten.
Oder vice versa. Hätte Python die Blockklammerregeln von C/C++
übernommen wie das beispielsweise C# gemacht hat, würde sich keiner
daran stören und die Fehleranfälligkeit diesbezüglich wäre geringer.
unechter Python-Programmierer schrieb:>> Umgekehrt würde sich aber heute vermutlich keiner über Python aufregen,>> wenn C gleich ohne die Klammern erfunden worden wäre. Dann würde man das>> als ganz normal betrachten.>> Oder vice versa. Hätte Python die Blockklammerregeln von C/C++> übernommen wie das beispielsweise C# gemacht hat, würde sich keiner> daran stören und die Fehleranfälligkeit diesbezüglich wäre geringer.
Wie oben schon geschrieben, sehe ich bei den Klammern durchaus
potenzielle Fehler, die mit der Python-Variante nicht passieren können.
Und das, was Vlad da schreibt, hab ich auch bereits oben aufgegriffen
und sehe das letztendlich eher als Vorteil von Python.
Die Leute aus den von ihm beschriebenen Horrorszenarien, die wie Kraut
und Rüben einrücken und Editoren benutzen, die dauernd den Code
umformatieren, sorgen gerne für unleserlichen Code und unbrauchbare
Commits. Da sie in Python zusätzlich zu nicht funktionierendem Code
führen, steckt da ganz automatisch mehr Disziplin dahinter.
Vlad Tepesch schrieb:> Das geht in Python imho nicht.
Richtig. Python kennt keine anonymen Blöcke.
Es kennt stattdessen das wesentlich mächtigere "with" Statement, welches
genau das macht, was man in C mit {}-Blöcken manuell zusammenschustert.
vimperator schrieb:> Vlad Tepesch schrieb:>> Das geht in Python imho nicht.>> Richtig. Python kennt keine anonymen Blöcke.> Es kennt stattdessen das wesentlich mächtigere "with" Statement, welches> genau das macht, was man in C mit {}-Blöcken manuell zusammenschustert.
Mächtiger als in C, ja, aber in C++ sind die Blöcke deutlich cooler als
in Python, das muss man leider zugeben. Das with-Statement in Python ist
im Endeffekt ein Workaround, um sowas wie den RAII-Pattern zu bauen
obwohl man einen Garbage Collector hat, wenn mir dieser Buzzword-Erguss
gestattet ist.
Leerzeichen als syntaktisches Element gab es schon vor Python:
Ich habe in den 80ern die Transputer (R.I.P) in Occam programmiert,
Fand als Student das Konzept faszinierend, allerdings wegen der
Dos-Fensterbreite (80 Zeichen!) konsequent meist nur 2 Leerzeichen zum
einrücken (Davon abgewichen wird von mir auch heute nur dort wo es von
Codier-Regeln zwingend verlangt wird. Es macht halt einen Unterschied ob
die Anweisung in Spalte 30 oder Spalte 60 beginnt, und deshalb dann der
Rest rechts abgeschnitten wird oder man dauernd horizontal scrollen
muss).
Es gab damals auch Editoren die das 'weg'falten unterstützt haben, es
wurde nur die Kopfzeile angezeigt. Damit war das dann absolut kein
Problem. Im Text selbst wurde dann aber als Kommentar {{{ }}} in
eigenen Zeilen vom Editor eingefügt (aber nicht angezeigt) weil der
Parser des Editors das mit damaliger Rechenleistung nicht gepackt hat.
Ich finde das einrücken von der Lesbarkeit solange akzeptabel, solange
die Blöcke klein genug bleiben. Beim klassischen Texteditor eine gleiche
Einrückung 500 Zeilen weiter unten zu finden ist für Mensch einfach zu
fehlerträchtig, das geht eben nur wenn der Editor das unterstützt,
ansonsten passieren Fehler, weie in den vorigen Beiträgen schon
geschildert: Tab / Blank Wechsel, Copy/Paste an falscher Stelle usw.
Kurze Scripte --> Python-Einrückung super, besser als Klammersn
Lange Scripte --> Sicheres Arbeiten mit Python geht nur wenn der Editor
das gut unterstützt und man darin geübt ist. Mit dem Standardeditor sehe
bei wirklich grossen Sourcen das Klammern per { } oder (auch
Pascal-Fan!) begin / end als sicherer.
Betonung hier auf SICHERER, nicht SCHÖNER!
Die paar Python-Scripte die ich geschrieben habe, sind alle grösseren
Blöcke per eingefügten Kommentaren abgeschlossen.
Ein anderes Negativ-Beispiel für Blank / Tab als problematisches
Syntax-Element ist MAKE, der Klassiker. Da hab ich es viel zu oft erlebt
dass mir falsch konfigurierte Editoren, Versionierungstools oder
sonstiges funktionerende Makefiles kaputt gemacht haben.
Parallel zu dem Einrückungs-Streit übrigens ärgere ich mich auch über
den Dogmatismus beim Zeilenumbruch: Warum kann der Default-Editor bei
Windows (Notepad) immer noch keine Dateimit nur LF umgebrochen anzeigen.
Genauso gibt es bei Unix-Shells dann die Fehlermeldung über nicht
akzeptierte CR's
Das Leben könnt so viel einfacher sine mit etwas mehr (Fehler-)Toleranz
auf allen Seiten.
Andersrum haben dadurch natürlich etliche Leute ihr sicheres Gehalt :-)
Allen Lesern eine gute Nacht vom PC-Oldie, der aber immer noch
mindestens 10 Jahre sich mit diesen Themen wird rumschlagen müssen.
Sven B. schrieb:> as muss man leider zugeben
Das gibt nur der Nicht-Python-Programmierer zu, denn er kennt das
with-statement nicht. Stattdessen frickelt er lieber coole {}-Blöcke
selbst.
vimperator schrieb:> Das gibt nur der Nicht-Python-Programmierer zu
Klar, Python-Programmierer geben schließlich nie irgendwas zu.
SCNR :-)
(Manche Leute scheinen ja mit ihrem Computer und ihrer
Programmiersprache verheiratet zu sein …)
pc_oldie schrieb:> Es macht halt einen Unterschied ob> die Anweisung in Spalte 30 oder Spalte 60 beginnt, und deshalb dann der> Rest rechts abgeschnitten wird oder man dauernd horizontal scrollen> muss).
Ich programmiere mit 8-space breiten Tabs als Einrückung und muss nie
horizontal scrollen.
Jetzt rate ich mal, wie ich das mache.
pc_oldie schrieb:> Genauso gibt es bei Unix-Shells dann die Fehlermeldung über nicht> akzeptierte CR's
Wir schreiben das Jahr fast-2015. Jeder benutzt UTF8-shells und
Terminals. Da ist sowas absolut kein Problem. Selbst mit latin1 oder
sowas ist es kein Problem.
Neben dem oben vorgeschlagenen "Python with Braces" gibt es übrigens bei
Python 2 das Tool pindent.py, das am Ende jedes Blocks eines korrekt
eingerückten Python-Programms eines der Tags
1
# end if
2
# end for
3
# end while
4
usw.
einfügt (Option -c), getagten Code automatisch richtig einrückt (Option
-r) oder die Tags wieder entfernt (Option -d).
Gegner der Blockmarkierung durch Einrückung brauchen also nur ihren
Editor so zu konfigurieren, dass Python-Dateien beim Laden durch
1
pindent.py -c
beim Speichern durch
1
pindent.py -d
und beim Neuformatieren durch
1
pindent.py -r
gefiltert werden.
Stören die Kommentarzeichen von der "end"-Tags, können sie durch eine
kleine Modifikation in pindent.py eliminiert werden, so dass das "end"
fürs Auge zu einem Schlüsselwort der Sprache wird. Da die Tags beim
Speichern automatisch entfernt werden, sind sie außerhalb der
Editorsitzung für niemanden sichtbar, so dass diese "Spracherweiterung"
keinerlei Inkompatibiltäten verursacht.
Jörg Wunsch schrieb:> (Manche Leute scheinen ja mit ihrem Computer und ihrer> Programmiersprache verheiratet zu sein …)
Verheiratet, das ist das Stichwort. Wie in einer guten Ehe: wenn man
nicht schnell genug irgendwas Nettes sagt, gibt es Ärger.
Deshalb schlagen wohl die ganzen Möchtegern-Pythonfreaks mit ihrem "Oh,
einrücken ist ja sooooo sexy und macht schöne Haut, aber nur, wenn ich
es muss; es ist total uncool und doof, wenn man sowas in
C/C++/Pascal/irgend einer anderen Sprache freiwillig macht" hier auf und
machen sich lächerlich resp. unsympathisch.
Naja, jeder wie er mag.
vimperator schrieb:> Yalu X. schrieb:>> keinerlei Inkompatibiltäten verursacht.>> außer, dass Zeilennummern nicht mehr stimmen.
Stimmt. Aber ein Tool zur Konvertierung der Zeilennummern zu schreiben
ist auch kein großer Aufwand.
pc_oldie schrieb:> Leerzeichen als syntaktisches Element gab es schon vor Python:
In make werden Tabs als syntaktisches Element verwendet.
Michael Krauth schrieb:> Deshalb schlagen wohl die ganzen Möchtegern-Pythonfreaks mit ihrem "Oh,> einrücken ist ja sooooo sexy und macht schöne Haut, aber nur, wenn ich> es muss; es ist total uncool und doof, wenn man sowas in> C/C++/Pascal/irgend einer anderen Sprache freiwillig macht" hier auf und> machen sich lächerlich resp. unsympathisch.
Soviel zum Thema "absurde Argumente"...
Rolf Magnus schrieb:> In make werden Tabs als syntaktisches Element verwendet.
Wobei man der Ehrlichkeit halber sagen muss: das ist eher eine
Jugendsünde denn eine Tugend. Das würde man heute, 40 Jahre später,
ganz gewiss nicht mehr so machen.
Jörg Wunsch schrieb:> Rolf Magnus schrieb:>> In make werden Tabs als syntaktisches Element verwendet.>> Wobei man der Ehrlichkeit halber sagen muss: das ist eher eine> Jugendsünde denn eine Tugend. Das würde man heute, 40 Jahre später,> ganz gewiss nicht mehr so machen.
Heute würde man sovieles anders machen, auch in C, C++, Python, Java,
Ruby, Haskell, im Maschinenbau, in der Medizin, in der Energieerzeugung
und überall.
Hinterher ist man immer schlauer, aber da ist das kind dann nicht nur in
den Brunnen gefallen, sondern auch schon abgesoffen.
Wenn ich heute jemandem Erzähle wie damals(tm) Käpt'n Crunch Telefone
gehackt hat, zeigen mir alle n Vogel, mit der Begründung: "Das is ja
total dumm, wie telefone damals funktioniert haben, welcher vollpfosten
hat sich das denn ausgedacht...", ja richtig, aber es gab halt nichts
anderes.
Und das ist bei Programmiersprachen und deren Werkzeuge nicht anders!
Sich hinterher hinstellen und klugscheißen, was alles scheiße ist, ist
immer leicht.
Kaj schrieb:> Und das ist bei Programmiersprachen und deren Werkzeuge nicht anders!
Ist nix dagegen zu sagen. Aber dann darf man eine nicht so glückliche
Entscheidung (wie eben die TABs bei "make") auch mal so benennen, statt
sie aufs Messer als das Beste seit der Erfindung von geschnittenem Brot
zu verteidigen. ;)
@Yalu
Yalu X. schrieb:> sollte in dieser Spalte zwischen dem "if"> und der schließenden Block-Ende-Klammer nur Leerraum stehen (s. Beispiel> 1 im Anhang).
in dem von dir genannten Beispiel bin ich voll bei dir.
Was aber wenn der conditionale Ausdurck deutlich komplexer ist?
1
if((something==-1)
2
&&(somethingelse==-1)
3
&&(etc==-1)){
4
code;
5
morecode...
6
}
Ich find es ziemlich schwer, so den Überblick zu behalten, wo die
Bedingung aufhört und der Code anfängt.
Da bevorzuge ich:
Vlad Tepesch schrieb:> Was aber wenn der conditionale Ausdurck deutlich komplexer ist?
Mir gefällt deine erste Alternative besser, allerdings würde ich den
umgebrochenen logischen Ausdruck noch etwas stärker einrücken, um die
Zusammengehörigkeit der einzelnen Teilausdrücke stärker hervorzuheben:
1
if((something==-1)
2
&&(somethingelse==-1)
3
&&(etc==-1)){
4
code;
5
morecode...
6
}
Wie schon oben geschrieben ist für mich die Beziehung zwischen dem "if"
und dem Blockende wichtiger als diejenige zwischen Blockanfang und
-ende. Deswegen finde ich auch
1
if bedingung
2
:
3
:
4
end
(wie in Ruby) besser zu lesen als
1
if bedingung then
2
begin
3
:
4
:
5
end
(wie in Pascal üblich).
Letzteres würde ich (sollte ich jemals wieder etwas in Pascal machen
;-)) so schreiben:
Noch etwas zur einrückungssensitiven Syntax:
Die hat schon sehr viel Tradition. Der pc_oldie brachte ja schon die
Beispiele Occam (1983) und Make (1977).
Man kann aber noch weiter zurückgehen: Die Sprache SASL (1972)
verwendete sie ebenfalls und war ihrerseits eine Implementation einer
Untermenge der abstrakten Sprache ISWIM (1966) von Peter Landin, der in
seinem Artikel
"The Next 700 Programming Languages"
auch den Begriff "off-side rule" für diese Art der syntaktischen
Festlegung der Programmstruktur prägte.
Auch in Fortran (1956) war die Einrückung des Codes wichtig, allerdings
aus anderen Gründen als der Blockstruktur (verschachtelte Blöcke gab es
dort damals noch keine).
Syntaktisch signifikanter Leerraum wird aber schon seit Jahrhunderten
ganz woanders, nämlich in der mathematischen Formelsprache, verwendet.
Dort ist sogar nicht nur horizontaler, sondern auch vertikaler Leerraum
relevant:
Alle fünf Ausdrücke bestehen aus den Symbolen '(', 'x', 'y' und ')' (in
dieser Reihenfolge), haben aber völlig unterschiedliche Bedeutungen.
Diese hängt alleine davon ab, ob der horizontale (h) und vertikale (v)
Leerraum zwischen dem 'x' und dem 'y' positiv, null oder negativ ist.
Das Problem des "Zerreißens" besteht auch hier: Es ist schon oft genug
vorgekommen, dass der Schriftsetzer eine Formel aus dem Manuskript des
Autors falsch übernommen hat, weil er die relative Position der Symbole
zueinander nicht richtig erkannt hat.
Trotz dieses nicht zu übersehenden Nachteils werden Formeln heute noch
fast genauso geschrieben wie vor hundert Jahren, ganz einfach deswegen,
weil sie so für die meisten am leichtesten zu lesen sind.
Und darauf kommt es letztendlich an, gerade auch bei der Programmierung.
Das Problem dort besteht halt darin, dass sich – anders als bei den
mathematischen Formeln – die Beteiligten bezüglich der Lesbarkeit der
möglichen Alternativen (noch) sehr uneinig sind.
Für mich persönlich ist die Reduktion von syntaktischem Rauschen fast
immer ein Gewinn und die Gefahr des "Zereißens" kaum relevant. Anderen
geht es aber offensichtlich anders, wie diese und ähnliche Diskussionen
beweisen.
Zum Glück hat man bei den Programmiersprachen eine deutlich größere
Auswahl als bei den mathematischen Formelsprachen. Deswegen würde ich,
wenn man diesbezüglich überhaupt irgendwo von "Zwang" spechen kann,
dies eher bei letzterer tun :)
Kaj schrieb:> Die Hölle muss sofort zu frieren... der C-Code sieht ja genauso aus wie> der Python-Code... ooops, wie konnte das nur passieren? Hier stört sich> kein Schwein an den fehlenden Klammern im C-Code, aber im Python-Code> ist das plötzlich scheiße, unleserliche und ein "no go"? Ernsthaft?
Ja, ernsthaft. Du hast nämlich was verpennt: Die Blockbildung. Ja, ist
auch ne Bildung..
Also: Blöcke pflegen im Allgemeinen etwas zu sein, mit dem man MEHRERE
einzelne Anweisungen zusammenfaßt und dann wie eine Anweisung im
übergeordneten Kontext benutzen kann. Das ist der tiefere Sinn der
ganzen Übung.
Du hast hier nur den trivialen (entarteten) Fall gepostet, wo jeder
Block nur eine einzige Anweisung enthält und damit eigentlich keine
Existenzberechtigung hat, außer ggf. der Klarstellung. Genau DAS ist
dein schlichter Denkfehler. Das ist (um mal wieder etwas Benzin in den
Kronleuchter zu gießen) so ähnlich wie in C while(1) oder for(;;) - die
Diskussion um goto hatten wir ja schon zur Genüge.
W.S.
Yalu X. schrieb:> Letzteres würde ich (sollte ich jemals wieder etwas in Pascal machen> ;-)) so schreiben:> if bedingung then begin> :> :> end
Ah, ja, ich erinnere mich: "Knüppel aus dem Sack!"
W.S.
W.S. schrieb:> einzelne Anweisungen zusammenfaßt und dann wie eine Anweisung im> übergeordneten Kontext benutzen kann
Gerade das ist in C ja auch erst seit "kurzem" (C99) möglich.
Stefan Salewski schrieb:> Yalu X. schrieb:>> Guido schreibt, dass len(x) besser als x.len() lesbar ist.>> Diesen Punkt haben Nim und D ganz nett gelöst, Funktionen f(a) bzw.> f(a,b, ...) können stets wahlweise auch mit Methodensyntax a.f bzw.> a.f(b, ...) aufgerufen werden.
Methodensyntax geht halt nur bei Single-Dispatch.
vimperator schrieb:> nein> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
Da verwechselst du zwei Dinge:
W.S. schrieb von Blöcken, die mehreren Anweisungen zu einer großen
Anweisung zusammenfügen. Die gab es schon in Ur-C.
Was du beschreibst, sind Statement-Expressions, die mehrere
Anweisungen zu einem Ausdruck zusammenfügen. Das gibt es in C bisher
tatsächlich nur als Spracherweiterung.
So, muss mir meinen Frust kurz von der Seele schreiben:
hab gerade stundenlang einem Bug nachgejagt. Konnte mir das Verhalten
des Skripts einfach nicht erklären, bis ich feststellen durfte dass ein
"break" zuweit eingerückt war und mir immer ungewollt die Schleife
abgebrochen hat.
Zum Kotzen!
Disclaimer:
ja, ich bin selbst schuld. Ja, ich hab einen Fehler gemacht. Ja, es
liegt an mir, ich bin zblöd zum Einrücken.
Trotzdem zum Kotzen!
unechter Python-Programmierer schrieb:> Es wird immer absurder hier sich die Zwangseinrückungen mit absurden> Kommentaren schön zu reden. Erst wird behauptet, das es den Code dadurch> "deutlich kompakter macht", als ob wir heutzutage noch alle auf einem> futzelkleinen EGA Monitor unter DOS rumhacken würden und unter> Zeilenarmut zu leiden hätten. Nun wird als Pro-Einrück-Argument> angeführt, man könne damit den Code schon aus "5 Meter Entfernung> deutlich erkennen". Das tut ja schon weh, was man hier so alles lesen> muss. Das sind Nichtargumente. Lasst euch mal was besseres einfallen.
Leute die von Zwangseinrückung reden haben die Diskussion einfach nicht
verstanden. Zwangseinrückung ist so sinnvoll wie Zwangsklammer,
Zwandssimekolon ... Was kompakten Code angeht, hat sich zwar die
Bildschirmfläche in den letzten 30 Jahren verzehnfacht, Das Gehirn ist
aber nicht mitgewachsen. Wer hier den linken Code schneller überschaut
und schöner findet, sollte sich mal untersuchen lassen:
Yalu X. schrieb:
Wer in Python Probleme hat weil er zuviel Einrücken muss, der sollte
sich nochmal mit Begriffen wie Strukturierung/Objektorientierung
vertraut machen. Gleiches gilt wenn man, wie der TO an einem Abschnitt
was ändert und dann auf einmal das ganze Programm nicht mehr arbeitet.
Das ist nicht die Einrückung das Problem, sondern die italienische
Teigware.
Karl schrieb:> Leute die von Zwangseinrückung reden haben die Diskussion einfach nicht> verstanden.
Nur, weil hier einer seinen Frust abgelassen hat, musst du jetzt nicht
sämtliche Argumente nochmal aufrollen. Es würde ohnehin nichts ändern,
es gibt halt Leute, die diese verpflichtende Einrückerei ganz toll
finden und welche, die sie für einen Missgriff halten. Keiner kann
den anderen vom Gegenteil überzeugen.
Benji schrieb:> hab gerade stundenlang einem Bug nachgejagt. Konnte mir das Verhalten> des Skripts einfach nicht erklären, bis ich feststellen durfte dass ein> "break" zuweit eingerückt war und mir immer ungewollt die Schleife> abgebrochen hat.> Zum Kotzen!
Das war der Grund dass ich damals als Python erschien schnell wieder die
Finger davon gelassen habe. Sprachen die durch einen unbeabsichtigten
Zeilenumbruch ihr Verhalten ändern sind ein no-go. Whitespace als
Syntaxelement ist zu Recht nur in Exoten/Experimentalsprachen vorhanden
die entweder ausgestorben sind oder eben Exotenstatus haben. Python ist
die einzige Sprache die es durch massives Gehype (deren ahnungslosen
Fanboys, je weniger Ahnung desto lauter das Geplärre) dennoch zu
nennenswerter Verbreitung und Relevanz gebracht hat. Für seriöse
Entwicklung taugt das absolut nicht, egal wieviel Successstories jetzt
wie aus der Pistole geschossen genannt werden, das ist einfach Müll.
Senior Scheffentwickler schrieb:> Python ist> die einzige Sprache die es durch massives Gehype (deren ahnungslosen> Fanboys, je weniger Ahnung desto lauter das Geplärre) dennoch zu> nennenswerter Verbreitung und Relevanz gebracht hat.
Blablabla. Nenn mir mal eine andere Sprache, mit der man so leicht und
flexibel wissenschaftliche Daten verarbeiten kann wie Python ...
Whitespace hin oder her, das geübte Auge erkennt das so oder so. Reine
Gewöhungssache. Und in C oder C++ kann man mit einzelnen Zeichen die
irgendwo falsch sind erheblich mehr Schaden und verwirrendes Verhalten
anrichten als in Python ... ja, auch wenn es Leerzeichen sind, zum
Beispiel in Makros oder Strings. Siehe den Underhanded C Contest als
Beispiel ;)
Sven B. schrieb:> Senior Scheffentwickler schrieb:>> Python ist>> die einzige Sprache die es durch massives Gehype (deren ahnungslosen>> Fanboys, je weniger Ahnung desto lauter das Geplärre) dennoch zu>> nennenswerter Verbreitung und Relevanz gebracht hat.>> Blablabla. Nenn mir mal eine andere Sprache, mit der man so leicht und> flexibel wissenschaftliche Daten verarbeiten kann wie Python ...
Jetzt wäre ein konkretes Beispiel hilfreich, das deine Argumentation
stützt.
Bernd schrieb:> Jetzt wäre ein konkretes Beispiel hilfreich, das deine Argumentation> stützt.
Python hat numpy und matplotlib, die sehr leicht verfügbar, gut gewartet
und sehr mächtig sind.
Ich kann in zwei Zeilen eine CSV-Datei laden, Fouriertransformieren und
das Ergebnis in einem interkativen Plotfenster darstellen. Und das Ganze
ist dank numpys cleverer Implementierung auch noch relativ schnell.
data = np.loadtxt("foo.csv")
plt.plot(np.abs(np.fft.rfft(data))
Ich kenne keine andere Sprache, in der Aufgaben dieser Art mit
vergleichbarem Aufwand und vergleichbarer Flexibilität lösbar sind.
Python ist schon toll, eigentlich.
Ich benutz es gerne für kleine Scripte um meine tägliche Arbeit zu
automatisieren, z.B. Exceldokumente parsen und Code generieren.
Für größere Projekte würd ichs aber ned benutzen wollen.
Und ja, ein Grund dafür sind die Whitespaces.
Ich hatte es auch schon dass ich im Notepad++ einen ganzen Block
eingerückt habe, aufgrund einer Leerzeile aber nicht erfasst habe dass
die nachfolgende Zeile auch noch zum Block gehört, diese dementsprechend
nicht eingerückt. Das gibt lustige Fehlersuche.
Python ist sehr gut, ja, aber hat auch seine Schwächen. Der Hype ist
enorm und m.M.n. nicht gerechtfertigt.
Sowas ist mir in fünf Jahren noch nie passiert, wirklich.
Ich sehe ehrlich gesagt keinen großen Hype um Python. Die Bibliotheken
(insb. numpy!) sind halt einfach konkurrenzlos gut, ich kenne keine
Sprache mit was vergleichbarem ...
Sven B. schrieb:> Sowas ist mir in fünf Jahren noch nie passiert, wirklich.
Mir in anderer Form auch schon. Insbesondere das Verschieben von
ganzen Textblöcken über Hierarchieebenen (weil man vielleicht ein
Stück Code irgendwo rausnehmen und in eine eigene Funktion packen
möchte) ist haarig, denn dabei muss man zwangsweise auf einem anderen
Niveau neu einrücken. In anderen Sprachen kann sowas der Texteditor
komplett allein reformatieren, in Python prinzipbedingt nicht.
> Ich sehe ehrlich gesagt keinen großen Hype um Python.
Doch, den gibt es schon. Es sind natürlich sehr oft einzelne Leute,
die zu evangelisieren anfangen und so tun, als wäre es das beste seit
der Erfindung geschnittenen Brots.
Allerdings kann man (wie bei allen religiösen Fanatikern) darüber am
besten einfach hinwegsehen, und die Sprache dann einfach so als
Werkzeug benutzen wie jede andere auch.
> Die Bibliotheken> (insb. numpy!) sind halt einfach konkurrenzlos gut, ich kenne keine> Sprache mit was vergleichbarem ...
Ja, gerade numpy und matplotlib sind für mich auch regelmäßig Argumente
für Python. Das mit den Einrückungen ist eher keins :), das nehme
ich dann einfach mal in Kauf. Ich rücke aber auch meine C- und
Perl-Programme ein, auch wenn mir diese Sprachen keine stilistischen
Absurditäten ihrer Schöpfer aufzudrängen versuchen. :-)
Sven B. schrieb:> Sowas ist mir in fünf Jahren noch nie passiert, wirklich.
Dann scheinst du konzentrierter zu arbeiten als ich ;-)
Grad bei copy&paste (wie Jörg Wunsch schon schrieb) muss man schon sehr
konzentriert sein, ein Editor der ganze Blöcke einrücken kann ist
eigentlich fast Pflicht (ok, benutzt man aber eh).
Sven B. schrieb:> Ich sehe ehrlich gesagt keinen großen Hype um Python
Bei Gnome ist man anscheinend komplett auf Python umgestiegen.
Keine Ahnung ob das rein rational entschieden wurde. Immer das richtige
Werkzeug...
Sven B. schrieb:> Die Bibliotheken (insb. numpy!) sind halt einfach konkurrenzlos gut,
Ohja, oder xldr und xlwt sind mir sehr wichtig geworden.
Jörg W. schrieb:> Mir in anderer Form auch schon. Insbesondere das Verschieben von> ganzen Textblöcken über Hierarchieebenen (weil man vielleicht ein> Stück Code irgendwo rausnehmen und in eine eigene Funktion packen> möchte) ist haarig, denn dabei muss man zwangsweise auf einem anderen> Niveau neu einrücken.
Ja, aber was kann dabei schiefgehen?
Du kopierst den Block, fügst ihn ein ... dann ist er immer noch
markiert. Dann drückst du Tab oder Shift+Tab, bis die Einrückungsebene
am Anfang zu der Zeile vor dem Eingefügten passt. Wenn du das falsch
machst, gibt es einen IndentError. Ich sehe keinen großen Raum für
Fehler...?
>> Ich sehe ehrlich gesagt keinen großen Hype um Python.> Doch, den gibt es schon. Es sind natürlich sehr oft einzelne Leute,> die zu evangelisieren anfangen und so tun, als wäre es das beste seit> der Erfindung geschnittenen Brots.
Stimmt schon. Gibt's aber um ausnahmslos jede Sprache, und ich sehe das
bei Python nicht mehr als bei anderen Sprachen. Eher weniger, verglichen
mit z.B. Haskell ...
> Allerdings kann man (wie bei allen religiösen Fanatikern) darüber am> besten einfach hinwegsehen, und die Sprache dann einfach so als> Werkzeug benutzen wie jede andere auch.
So ist es.
Sven B. schrieb:> Ich sehe keinen großen Raum für> Fehler...?
Solange das so schön mit dem ganzen Block klappt, OK. Wehe, wenn
man das aus mehreren Teilen stückeln möchte oder so. Und nein, das
Problem sind nicht die IndentErrors, sondern wenn sich dann durch
fehlerhafte Einrückung die komplette Logik ändert.
Kann ja sein, dass man sich durch überflüssige "pass"-Statements
da retten kann (um das logische Ende eines bestimmten Teils zu
markieren, wurde oben irgendwo vorgeschlagen), aber das ist
dann auch irgendwie lästiger Schreibaufwand.
> Stimmt schon. Gibt's aber um ausnahmslos jede Sprache, und ich sehe das> bei Python nicht mehr als bei anderen Sprachen. Eher weniger, verglichen> mit z.B. Haskell ...
Die sind mir bislang noch nicht übern Weg gelaufen.
Jörg W. schrieb:> Sven B. schrieb:>> Sowas ist mir in fünf Jahren noch nie passiert, wirklich.>> Mir in anderer Form auch schon. Insbesondere das Verschieben von> ganzen Textblöcken über Hierarchieebenen (weil man vielleicht ein> Stück Code irgendwo rausnehmen und in eine eigene Funktion packen> möchte) ist haarig, denn dabei muss man zwangsweise auf einem anderen> Niveau neu einrücken.
Nicht, daß mir einige Merkwürdigkeiten im Python-Biotop nicht auch sauer
aufstießen (z.B. die versuchte Selbstdemontage durch die 2->3-Spaltung),
aber das ist mir in >10 Jahren Python auch noch nicht passiert. Es mag
daran liegen, daß ich für das Bearbeiten von Code nahezu ausschließlich
SciTE (http://www.scintilla.org/SciTE.html) benutze. Da ist das
Neueinrücken eines markierten Blocks i.W. ein Tastendruck. Es hat mich
immer mal wieder gejuckt, tabnanny
(https://docs.python.org/2/library/tabnanny.html) an passenden Stellen
einzubauen, der Leidensdruck war aber nie hoch genug oder überhaupt
vorhanden.
> In anderen Sprachen kann sowas der Texteditor> komplett allein reformatieren, in Python prinzipbedingt nicht.
Warum soll das prinzipbedingt nicht gehen? Die Python-Einrückung ist
formal äquivalent einer expliziten Klammerung. Tatsächlich werden beim
Parsen so etwas wie Klammerungstoken generiert.
Alles, was üblicherweise in anderen Sprachen gemacht wird, ist die in
der Indentation steckende Information wegzuwerfen und die expliziten
Klammern zu verwenden.
Natürlich gibt es in Python genau so verschiedene Indentation-Styles, so
wie die unterschiedlichen Stile ("K&R", "GNU", "Whitesmith", ...) in C.
Wenn Du automatisch eine kanonische Indentation eines Python-Programms
erzeugen möchtest, kein Problem: "pip install autopep8", "autpep8
beispiel.py". Probier's aus.
>>> Ich sehe ehrlich gesagt keinen großen Hype um Python.>> Doch, den gibt es schon. Es sind natürlich sehr oft einzelne Leute,> die zu evangelisieren anfangen und so tun, als wäre es das beste seit> der Erfindung geschnittenen Brots.
Gibt es, wie bei allen Sprachen. Oder bei Prozessorfamilien. :-}
>> Allerdings kann man (wie bei allen religiösen Fanatikern) darüber am> besten einfach hinwegsehen, und die Sprache dann einfach so als> Werkzeug benutzen wie jede andere auch.
Eben. Nachdem ich mir letztes Jahr sowohl Micropython auf dem ESP8266
als auch NodeMCU (i.e. Lua auf dem ESP8266) angeschaut habe, ziehe ich
ganz entschieden Lua vor. Obwohl ich mit Lua bisher kaum praktische
Erfahrung habe.
Und das ist der Punkt: normalerweise zieht man das vor, was man kennt,
und dagegen ist auch überhaupt nichts einzuwenden. Und aus genau dem
Grunde gehen mir die Leute auf die Nerven, die jedem ins Wort fallen,
der einfach aus seinen eigenen Erfahrungen berichtet, ohne damit
unbedingt eine Wertung verbinden zu wollen.
Vor allem nervt dieses Getue, wenn man selber vor vielen Jahren auf den
einen odere anderen Zug aufgesprungen ist, laaange bevor daraus
vielleicht irgend ein Hype geworden ist, eben weil man auch immer
wieder über den Tellerrand schaut und sich jenseits von Hype und
Bullshit ein Urteil bilden kann. Und einem dann später, meist
ausgerechnet von Neulingen mit ziemlich verengtem Horizont, entweder
gerade im Hypecycle oben angekommene Technologie angepriesen oder das
Hinterherlaufen hinter einem Hype vorgeworfen wird - meist sogar beides
gleichzeitig.
Wolfgang S. schrieb:>> In anderen Sprachen kann sowas der Texteditor>> komplett allein reformatieren, in Python prinzipbedingt nicht.>> Warum soll das prinzipbedingt nicht gehen?
Weil ich in C meinem Editor sagen kann, dass er ein verwurschteltes
Textstück wie:
1
if(something){
2
foobar();
3
m=mumble();
4
barfoo();
5
}
6
else{
7
returnERROR;
8
}
einfach mal grundlegend entsprechend dem aktuellen Einrückungsniveau
neu sortieren soll.
Die Einrückung ist dort nur "nice to have" (macht natürlich trotzdem
jeder, auch ganz ohne Zwang), aber die grundlegende Struktur wird
durch sie nicht beschrieben, sondern durch andere Elemente.
Sven B. schrieb:> data = np.loadtxt("foo.csv")> plt.plot(np.abs(np.fft.rfft(data))>> Ich kenne keine andere Sprache, in der Aufgaben dieser Art mit> vergleichbarem Aufwand und vergleichbarer Flexibilität lösbar sind.
Schon interessant dein Statement. Die beiden Zeilen machen doch nichts
anderes als Komplexität an anderer Stelle zu verstecken und genau das
machen typischerweise die ganzen "BASIC Dialekte". Ich brauche (hier)
kein Fenster zur Ausgabe eröffnen auf das ich mich zu beziehen haben
(ist schon irgendwie vorhanden). Ich brauche hier kein Objekt anlegen
oder Variable "data" deklarieren (ist schon implizit irgendwo anders
geschehen). Ich brauche mich anders als z.B. in C einen Kehricht um
einen Filepointer scheren, den vorher zu deklarieren und den Dateityp
anzugeben (dafür gibt es hier einen Spezialbefehl "loadtxt"). Ich
brauche kein Objekt zum Plotten anzulegen bzw. auch das wird implizit
bereits erledigt usw. usw.
Ich vermute mal sowas wie Purebasic (kenne es nicht näher) könnte das
ganz genauso leicht mit wenigen Zeilen erledigen oder Processing oder ..
Ich verstehe nur nicht warum das eine immer so abgewertet und belächelt
wird (von gewissen Naturen) und um das andere ein Hype gemacht wird.
Beides ist doch darauf angelegt es Leuten möglichst einfach zu machen
mit den aller nötigsten Zeilen "großes" zu bewirken und sich den Krampf
zu ersparen, den man z.B. in C treiben muss alleine um nur ein Fenster
unter Windows in Erscheinung zu bringen. Und um Geschwindigkeit geht es
Interpreter-Skriptsprachen wie Python doch gleich überhaupt nicht.
Nur mal so als kleine Randbemerkung.
Sven B. schrieb:> data = np.loadtxt("foo.csv")> plt.plot(np.abs(np.fft.rfft(data))>> Ich kenne keine andere Sprache, in der Aufgaben dieser Art mit> vergleichbarem Aufwand und vergleichbarer Flexibilität lösbar sind.
R vielleicht noch. Aber die Sprache dort ist... gewöhnungsbedürftig.
Jörg W. schrieb:> Wolfgang S. schrieb:>>> In anderen Sprachen kann sowas der Texteditor>>> komplett allein reformatieren, in Python prinzipbedingt nicht.>>>> Warum soll das prinzipbedingt nicht gehen?>> Weil ich in C meinem Editor sagen kann, dass er ein verwurschteltes> Textstück wie:>>
1
>if(something){
2
>foobar();
3
>m=mumble();
4
>barfoo();
5
>}
6
>else{
7
>returnERROR;
8
>}
9
>
>> einfach mal grundlegend entsprechend dem aktuellen Einrückungsniveau> neu sortieren soll.
Verstehe ich nicht. Wie wird das "aktuelle Einrückungsniveau" konkret
genutzt, was bedeutet "neu sortieren" und was ist dann das Ergebnis?
>> Die Einrückung ist dort nur "nice to have" (macht natürlich trotzdem> jeder, auch ganz ohne Zwang), aber die grundlegende Struktur wird> durch sie nicht beschrieben, sondern durch andere Elemente.
Ja, genau das schrieb ich bereits. Die beiden Denotatationen sind
äquivalent. In C sind die Klammern explizit, die redundante Einrückung
wird beim Neuformatieren als nicht syntaktisch relevant schlicht
ignoriert. In Python ist es umgekehrt, da wird die Klammerung durch die
Einrückung ausgedrückt und kann beim Neuformatieren genau so verwendet
werden wie beim Kompilieren. Niemand hindert Dich, redundante Klammern
als Kommentare reinzuschreiben, die dann beim Reformatieren genau so
ignoriert werden wie die Einrückung bei C. :-}
Jörg W. schrieb:> In anderen Sprachen kann sowas der Texteditor> komplett allein reformatieren, in Python prinzipbedingt nicht.
Gute IDEs für Python machen das.
Und normale Editoren können auch ganze Blöcke einrücken und ausrücken,
also Du fügst den ganzen Block ein und dann rückst Du ihn halt passend
ein.
Unter Sprachen mit Klammern würdest Du das genauso machen, obwohls die
Klammern dort auch so kompilieren lassen würden rückt man es auch dort
stets sofort korrekt ein und rückt verrutschte Klammern sofort wieder
zurecht weil es sonst einfach Scheiße aussieht und man sofort den
Überblick verliert.
Wolfgang S. schrieb:> Verstehe ich nicht.
Dann kann ich dir leider auch nicht helfen.
Ich werde Python sicher auch weiterhin benutzen, aber genauso werde
ich mich auch weiter hin und wieder über diesen Whitespace-Wahn
ärgern, und dieses Misfeature lass ich mir auch von keinem schön
reden. Whitespace zum signifikanten Sprachelement zu machen, hat
sich ansonsten nur die gleichnamige Programmiersprache erlaubt, aber
die ist ja wohl eher ein Gag.
Jörg W. schrieb:> Kann ja sein, dass man sich durch überflüssige "pass"-Statements> da retten kann (um das logische Ende eines bestimmten Teils zu> markieren,
Das ist Unsinn. Das logische Ende eines Blocks sieht man aus 5 Metern
Entfernung durch das Ende der Einrückung. Man muss schon halb blind sein
um sowas zu übersehen.
Bernd K. schrieb:> Das ist Unsinn.
Das ist schön, wenn das für dich Unsinn ist.
Für mich ist es leider (hin und wieder) Realität.
Und nein, ich möchte auch keine separate IDE für irgendeine
Programmiersprache haben.
Jörg W. schrieb:> Wolfgang S. schrieb:>> Verstehe ich nicht.>> Dann kann ich dir leider auch nicht helfen.
Ich versuchte "das ist Unsinn" höflich auszudrücken. Wie man sieht, ist
Höflichkeit manchmal nicht hilfreich. :-}
Aber ok, wenn Du die konkrete Frage
Wie wird das "aktuelle Einrückungsniveau" konkret
genutzt, was bedeutet "neu sortieren" und was ist
dann das Ergebnis?
nicht beantworten möchtest, auch recht. Ich wollte nur helfen bzw. ein
Mißverständnis aufklären.
>> Ich werde Python sicher auch weiterhin benutzen, aber genauso werde> ich mich auch weiter hin und wieder über diesen Whitespace-Wahn> ärgern, und dieses Misfeature lass ich mir auch von keinem schön> reden.
Das ist mir so was von egal. Ob man die abstrakte Klammerung durch
Einrückung (nicht "white-space") ausdrückt oder durch explizite
Klammern, ist eine Geschmacksfrage. Darüber mag ich nicht streiten und
hier schon gar nicht.
Wenn eine lautstark vorgetragene Ablehnung aber mit offensichtlich
fehlerhaften Begründungen unterfüttert wird, ist ein gelegentlicher
Widerspruch aber schon nötig, sonst setzt sich das fest.
> Whitespace zum signifikanten Sprachelement zu machen, hat> sich ansonsten nur die gleichnamige Programmiersprache erlaubt, aber> die ist ja wohl eher ein Gag.
Whitespace ist, vom Einrückungsniveau abgesehen, in Python genau so viel
oder wenig signifikant wie in anderen herkömmlichen Programmiersprachen.
ach naja schrieb:> Sven B. schrieb:>> data = np.loadtxt("foo.csv")>> plt.plot(np.abs(np.fft.rfft(data))>>>> Ich kenne keine andere Sprache, in der Aufgaben dieser Art mit>> vergleichbarem Aufwand und vergleichbarer Flexibilität lösbar sind.>> Schon interessant dein Statement. Die beiden Zeilen machen doch nichts> anderes als Komplexität an anderer Stelle zu verstecken und genau das> machen typischerweise die ganzen "BASIC Dialekte".
Theoretisch ja. Aber in der Praxis, gibt es eine
quasi-Standardbibliothek, die CSVs laden, Fouriertransformationen
rechnen und interaktive Plotfenster öffnen kann, und das mit so einer
einfachen API und so schnell?
Natürlich hat das nur wenig mit der Sprache zu tun, Sprachen sind ...
nicht besonders wichtig. Ich würde numpy auch mit der LISP-Syntax
benutzen, wenn das halt das wäre wofür es entworfen wäre. Aber es ist
nunmal für Python und deshalb ist Python für mich für solcherart
Anwendungen die Sprache der Wahl.
Jörg W. schrieb:> Und nein, ich möchte auch keine separate IDE für irgendeine> Programmiersprache haben.
Es gibt IDEs da wird eine neue Sprache über ein Plugin unterstützt, da
braucht man nicht jedesmal eine neue IDE. Für Eclipse wäre das z.B.
PyDev. Und ja, das will man haben denn dabei erhält man Werkzeuge die
die Sprache parsen und dem Nutzer damit behilflich sein können. Zum
Beispiel um das andere Ende des Blocks zu finden (andere Klammer, das
end zum begin, das andere Ende von irgendwas. Oder Aufrufbäume und
Aufruferbäume anzeigen lassen, oder auf Knopfdruck Methoden
implementieren oder zur Deklaration/Definition von irgendwas springen,
oder sich auflisten lassen wer diese Variable verwendet, und sie mit
einem Knopfdruck SICHER umbenennen können obwohl sie an 142 anderen
Stellen verwendet wird unter Berücksichtigung aller Sichtbarkeitsregeln,
oder die Signatur einer Funktion beim Aufruf derselben in einem kleinen
Calltip anzeigen, oder auf Knopfdruck Methoden eines Objekts auflisten
oder alle im momentanen Scope sichtbaren Bezeichner die mit foo anfangen
anzeigen lassen, oder statische Code-Analyse bzw. Lint durchführen, oder
wie von Dir gewünscht beim Copy/Paste passend einzurücken. All das will
man in seinem Editor drin haben wenn man täglich mehr und komplexeren
Code und mehr verschiedene Projekte um die Ohren hat als einem lieb ist.
Bernd K. schrieb:> und sie mit> einem Knopfdruck SICHER umbenennen können obwohl sie an 142 anderen> Stellen verwendet wird unter Berücksichtigung aller Sichtbarkeitsregeln,
Das ist in Python übrigens völlig unmöglich, kann ich dir sagen. ;)
Jörg W. schrieb:> Ich werde Python sicher auch weiterhin benutzen, aber genauso werde> ich mich auch weiter hin und wieder über diesen Whitespace-Wahn> ärgern, und dieses Misfeature lass ich mir auch von keinem schön> reden. Whitespace zum signifikanten Sprachelement zu machen, hat> sich ansonsten nur die gleichnamige Programmiersprache erlaubt, aber> die ist ja wohl eher ein Gag.
Ich hatte ja vor langer Zeit schon mal versucht es Dir zu erklären,
einige andere auch. Aber irgendwie magst Du es nicht so recht einsehen?
Die Einrückungen werden zur Strukturierung des Quelltextes verwendet,
wie sonst eben {} oder begin/end. Das hat doch überhaupt nichts mit
willkürlichem Zwang zu tun. Irgendwie muss die Struktur ja dargestellt
werden. Und so spart man sich eben Elemente wie {} oder begin/end oder
sonstwas. Ob man das nun gut findet oder nicht, ist ja eine andere
Sache. Weitgehend ist das auch von der Gewöhnung abhängig. Für mich
persönlich ist die Einrückung meistens vorzuziehen, etwa bei sehr langen
Blöcken eher nicht, da mache ich mir manchmal ein #end irghendwo hin.
Übrigens auch Nim und Haskell verwenden diese Art der Strukturierung.
Sven B. schrieb:> Make übrigens auch, da hat noch keiner gemotzt ;)
Make ist schlimmer. Die benutzen explizit einen führenden TAB, das
darf nichts anderes sein, was ein Kommando einleitet. Führende
Leerzeichen wiederum darf man einer Makro-Zuweisung voranstellen.
Aber Python ist deutlich nach Make entstanden, da wusste man eigentlich
schon, dass das ein Fehler war …
Jörg W. schrieb:> Aber Python ist deutlich nach Make entstanden, da wusste man eigentlich> schon, dass das ein Fehler war …
Korrekt.
Wäre es nicht möglich, Python-Code so zu schreiben wie man es von
C
C++
Java
C#
usw. gewohnt ist, und dann ein Skript drüber laufen zu lassen welches
die { } entsprechend in Einrückungen umwandelt?
Mark B. schrieb:> Wäre es nicht möglich
Vielleicht, aber das passt nicht in eine vernünftige Arbeitsweise
rein. Dann ärgere ich mich doch lieber mit den Einrückungen 'rum,
auch wenn ich sie als keine kluge Designentscheidung empfinde.
Es gibt auch Dinge in bspw. C, die keine klugen Designentscheidungen
sind (wie das implizite "extern" globaler Objekte und Funktionen,
sodass man immer extra "static" schreiben muss), mit denen man genauso
zu leben gelernt hat.
Eric B. schrieb:> Im Notepad++ muss ich nur die Zeilen die einzurücken sind selektieren,> drücke einmal [TAB] oder [SHIFT]+[TAB] und schon ist es erledigt.>> Nervig wird es wenn man mit mehrere Programmierern zusammenarbetien muss> und der eine Tabs zum einrücken benutzt, der andere 2 Leerzeichen und> der dritte 4 Leerzeichen |-(
Selbes geht mit fast jedem anderen Editor auch, z.B. bei mir kwrite.
Wenn man Copy-Pasted: Einfügen, eingefügten Block auswählen, passend Tab
drücken (evtl. leerzeichen / tabs werden dann in die eingestellte Form
umgewandelt).
Das mit dem Mischen ist wirklich nervig, bei python2 warnt ein python
-t.
Bei Python 3 geht das erst gar nicht, führt dann zu Fehlern.
Ich schätze die Strukturrierung des Quellcodes nur durch Einrückungen
auch nicht, und gebe den Argumenten von Jörg Wunsch vollkommen recht.
Python benutze ich nur, wenn es gar nicht anders geht.
Was er mit den automatischen Sortierten einrücken meinte:
Der C Code ist total unleserlich formatiert. Es sollte nicht passieren,
aber wenn es so ist, ist es kein Beinbruch(kann aber auch nur einfach
den eigenen Kodierrichtlinien nicht entsprechen), da die funktionale
Struktur durch die Klammern gebildet wird. Auf deren Grundlage kann man
einen Parser über den Quellcode schicken, der ihn dann wieder vernüftig
formatieren kann. Das ganze ohne, das die logische Funktion geändert
wird.
Nur wenn wie bei Python eben Einrückungen die Funktionsweise
beeinflussen und es keine Klammern oder begin und end gibt, gibt es
prinzipbedingt keine Möglichkeit, den Code automatisch wieder korrekt zu
formatieren. Denn wenn der nicht korrekt eingerückt ist, kann ein Parser
die in dem moment unkorrekten Leerzeichen oder Tabs nicht als
Orientierung benutzen.
Ausserdem lösen Kodierungsrichtlinien das Problem mit der
unterschiedlichen Formatierungen Tab, 2 oder 4 Leerzeichen nur innerhalb
eines Teams. Aber es passiert oft, das man auch externen Code benutzt.
Ich sehe mit Pythion da sehr grosse Unsicherheiten bei der
Wiederverwendung von Code.
Immer wieder wird auch betont einen guten und korrekt eingestellten
Editor als Werkzeug bei der Pythonprogrammierung zu benutzen. Daraus
ergeben sich 2 weitere Argumente gegen Python.
1) Den Editor kann man sich nicht immer aussuchen, siehe Pythoneditor
integriert in Blender. Wer effektiv mit der Blenderoberfläche arbeiten
möchte sollte keinen externen Editor benutzen. Ok, der Blender Editor
hat Funktionen Tab oder Leerzeichen einzustellen, bzw. beides ineinander
zu konvertieren. Leider funktioniert das nicht sicher. Ich musste schon
oft den Quellcode im Notepad++ bearbeiten und wieder zurückkopieren, da
ich im Blender-Editor keine Möglichkeit gefunden habe, unsichtbare
Zeichen anzeigen zu lassen.
2) Was viel wichtiger ist! Eine Sprache die so abhängig von einem Editor
ist, ist letztlich für eine robuste und/oder sicherheitsrelevante
Programmierung nicht geeignet.
Eventuell sollten wir auch keine Äpfel mit Birnen vergleichen. Jede
Sprache sollte dafür eingesetzt werden, wofür sie geeignet und gedacht
ist. Mit der folgenden beispielhaften Einteilung kann ich gut leben:
C -> Embedded Firmware
C++ -> Windows Applikationen
Python -> unterstützende Skripte
Zur Ergänzung noch. Mir ist es auch schon mit Python beim copy und paste
passiert, das nur eine Zeile um eine Spalte falsch eingerückt war,
wodurch es längere Zeit gedauert hat, den Fehler zu finden und zu
beseitigen.
Wem das nicht passiert sei froh, es erleichtert die Programmierung
ungemein. Aber wir sind Menschen, und es ist menschlich Fehler zu
machen. Aus diesem Grund ist mittlerweile die Grenze zwischen statischer
Codeanalyse und Compilierung zum Teil fliessend geworden.
Werkzeuge sollten den Programmierer unterstützen Fehler zu vermeiden.
Aber genau das tut Python hinsichtlich einer korrekten Blockbildung
nicht, und das empfinde ich als Rückschritt.
Decius schrieb:> 2) Was viel wichtiger ist! Eine Sprache die so abhängig von einem Editor> ist, ist letztlich für eine robuste und/oder sicherheitsrelevante> Programmierung nicht geeignet.
Wo siehst du, dass Python für "sicherheitsrelevante Programmierung"
eingesetzt wird? Ich benutze das zur Datenanalyse.
Nicht jede Sprache muss jeden Zweck erfüllen.
C wird überall eingesetzt, und "robust" ist wirklich keine Stärke von C.
Ein Tippfehler irgendwo oder eine vergessene Zeile, und es kann wirklich
alles Mögliche passieren. Da ist Python im Laufzeitverhalten finde ich
deutlich vorhersehbarer.
> Zur Ergänzung noch. Mir ist es auch schon mit Python beim copy und paste> passiert, das nur eine Zeile um eine Spalte falsch eingerückt war,> wodurch es längere Zeit gedauert hat, den Fehler zu finden und zu> beseitigen.
Das Problem verstehe ich nicht. Ich verstehe weder wie das passieren
kann, noch wie man das nicht sofort erkennt (das sieht doch im Editor
total schief aus).
Außerdem, komische Syntaxfehler die schwer zu finden sind können in
jeder mir bekannten Sprache passieren, und Python ist jetzt da wirklich
nicht die schlimmste.
Das ist alles ein Nicht-Problem.
Diese Art von "Beschwerden" liest man regelmäßig nur von Leuten die
entweder überhaupt kein Python verwenden und nur die Vermutungen vom
Hörensagen nachplappern die andere Nichtverwender sich aus den Fingern
gesaugt und mit absurden erfundenen Szenarien "begründet" haben. Dieser
Thread ist voll von Blinden die stundenlang über Farben diskutieren.
Jemand der alle Jubeljahre mal 3 Zeilen Python schreibt zählt nicht als
jemand der Python regelmäßig verwendet.
Jeder der Python regelmäßig verwendet liebt die Blockbildung durch
Einrückung und den damit einhergehenden Wegfall der lästigen redundanten
Klammern.
Blockbildung durch Einrückung ist intuitiv und naheliegend: Man Zeige
mir zum Beispiel bitte mal einen einzigen von einem Nichtprogrammierer
erstellten Text mit verschachtelten Aufzählungen, Blöcken oder Gruppen
(könnte ein Einkaufszettel sein oder sonstwas) bei denen Blockbildung
oder Gruppierung mit geschweiften Klammern ausgedrückt wurde: Absurd.
Nur Programmierer kämen auf so eine Idee.
Außerhalb des Programmierens wird Gruppierung und Blockbildung
grundsätzlich unter Zuhilfenahme von Einrückung und Formatierung
ausgedrückt, manchmal auch durch Nummerierung oder Bulletpoints
(wiederum eingerückt) aber niemals mit paarigen Klammern. Sogar Oma kann
Einrückung ganz intuitiv verstehen und auch selbst anwenden. Sie käme
nie auf die Idee geschweifte Klammern zu setzen um die Einkäufe von
Edeka zu denen von Lidl abzugrenzen.
Bernd K. schrieb:> Diese Art von "Beschwerden" liest man regelmäßig nur von Leuten die> entweder überhaupt kein Python verwenden und nur die Vermutungen vom> Hörensagen nachplappern die andere Nichtverwender sich aus den Fingern> gesaugt und mit absurden erfundenen Szenarien "begründet" haben.
Es ist prima, dass du weißt, was ich mache.
Damit erübrigt sich jegliche Diskussion, denn selbstverständlich hast
du auf diese Weise immer recht, da ja im Zweifelsfalle dein Gegenüber
einfach als „der benutzt doch gar kein Python!“ abqualifiziert wird.
Wer Python nicht so benutzt und nicht so mag wie du, ist eben kein
richtiger Python-Programmierer.
Tschüss.
Jörg W. schrieb:> Es ist prima, dass du weißt, was ich mache.
Doch manche Sachen kann ich aus Deinen Äußerungen inferieren. Zum
Beispiel weiß ich daß Du Dich über mangelnde Unterstützung Deines
Editors für Python-Syntax (Einrückungen) beklagst, bis hin zu der
absurden Behauptung es wäre überhaupt grundsätzlich unmöglich diese
Python-Syntax in einem Editor in geeigneter Weise zu unterstützen, dann
auf meinen Hinweis daß es sehr wohl Editoren mit den geforderten
Eigenschaften gibt, antwortest Du daß Du so einen Editor überhaupt nicht
haben willst.
Daraus ist zu schließen daß bei Dir Python höchstens unter ferner liefen
eingeordnet ist mit null Priorität.
Als mit Python neueingestiegener und mit 50+ späteingestiegener
ehemaliger Nichtprogrammierer kann ich Bernd K.'s Argumenten durchaus
etwas abgewinnen. Allerdings hätte ich zur Meidung von Emotionen bei der
Argumentation auf die Kategorizität verzichtet.
Denn wo es keine Emotionen gibt, gibt es kein Motiv für Unlogik.
/schpock
Oh Gott ...
Das erinnert irgendwie an Arduino vs. "richtigem AVR" etc.
Es ist mir vollkommen wurscht, mit welcher Sprache ich programmiere -
ich rücke immer ein. Alleine, um zu erkennen, was ich da mache. O.K.,
viele Editoren unterstützen dabei und rücken mehr oder weniger
intelligent ein - aber (zumindest ich) erkenne nur so die Struktur.
Ich hasse Programme, die einfach so - ohne Einrückung -
runtergeschrieben sind. Ich habe auch in C so meine Vorstellung, wie ein
Programm auszusehen hat (die { Klammer gehört für mich in die
Folge-Zeile ...) - ist ja auch egal, jeder so, wie er es mag.
Ich habe Cobol, Pascal, PL/1, ABAP, Basic, C und auch etwas C++
programmiert - seit einiger Zeit auch Python - egal welche Sprache, wenn
man es nicht ordentlich strukturiert (einrückt) wird es unleserlich.
Wo es noch nicht so gute Entwicklungsumgebungen gab habe ich mir
entsprechende Programme geschrieben, die mir in einer Art Parsing
Programm-Coding strukturiert haben, um es Lesen zu können.
Python kenne ich erst seit kurzem - und mag die Flexibilität und die
"Mächtigkeit". Der Einrück-Zwang stört mich überhaupt nicht - im
Gegenteil :-)
Ich finde es extrem elegant, dass man sich um die Plattform eigentlich
so gut wie keine Gedanken machen muss. Fast wie Arduino auf MC-Seite.
Wobei ich Arduino nur gelegentlich einsetze und den MC lieber in C
programmiere, da ich dann weiß, was ich tue (in Assembler natürlich noch
viel besser - aber das ist mir zu kryptisch).
Auf PC-Seite habe ich mich bisher nur wenig bewegt, daher reicht mir
Python vollkommen aus. Ich habe auch ein wenig mit C++ gespielt, finde
aber alles nicht so besonders übersichtlich. Ist aber eine rein
persönliche Einstellung.
Kurz: Einrückung stört mich überhaupt nicht, im Gegenteil!
Wenn ich dann z.B. PyCharm nutze wird mir die Einrückung sogar noch
elegant angezeigt :)
Bernd K. schrieb:> Jeder der Python regelmäßig verwendet liebt die Blockbildung durch> Einrückung und den damit einhergehenden Wegfall der lästigen redundanten> Klammern.
Also "ALLE" lieben das was DU magst? Meinst du nicht, du überhöhst dich
hier künstlich selbst, nach dem Motto, was ICH mag müssen ALLE lieben?!
> Blockbildung durch Einrückung ist intuitiv
Zusammenhängende Blöcke werden in der Textverarbeitung vor allem durch
Absätze, d.h. Leerzeilen dazwischen gebildet und nicht durch
Einrückungen. SO wird im übrigen auch gepostet, d.h. Absatzbildung ist
des Posters Stilmittel und nicht Einrückungen.
Im Übrigen kann von "Redundanz" schon deswegen gar keine Rede sein, weil
Klammern hier eben nicht einfach weggelassen werden können (nur dann
wären sie wirklich redundant, d.h. "überflüssig"), sondern an deren
Stelle MUSS zwangsläufig ein explizites Schema treten den Code in
bestimmter Abfolge anzuordnen (eben durch Einrückung) und das macht für
viele den Python Code insbesondere beim Austausch (wie hier zu lesen
ist) eben anfälliger für Fehler als man gemeinhin annimmt.
Ich will das Einrücken grundsätzlich aber gar nicht kritisieren. Es ist
einfach so wie es ist bzw. wie dieser Dialekt es eben vorsieht und man
muss sich drauf einstellen.
> Sogar Oma kann> Einrückung ganz intuitiv verstehen und auch selbst anwenden. Sie käme> nie auf die Idee geschweifte Klammern zu setzen um die Einkäufe von> Edeka zu denen von Lidl abzugrenzen.
Was meinst du wie oft "Oma" ihren eigenen Zettel im Supermarkt nicht
mehr richtig entziffern kann (ich erlebe das häufig in der
Verwandtschaft) und was meinst du käme erst für ein Kauderwelsch bei
raus, wenn ANDERE der lieben Oma ihren Einkaufszettel "verarbeiten"
müssten. Omas Zettel ist nämlich in der Regel chiffriert mit einem
Spezial-Geheimcode an Schreibschrift-Hieroglyphen aus ihrer Jugend. Lass
dir mal einen Brief von Oma schreiben. Du wirst staunen wie manche noch
schreiben (können) und Zeitalter der Blockbuchstaben.
PS: Nicht aufregen, Python ist nett.
Bernd K. schrieb:> Doch manche Sachen kann ich aus Deinen Äußerungen inferieren.
Insbesondere kannst du irgendwas hineininterpretieren, was ich gar
nicht (so) geschrieben habe. Hauptsache, es passt in dein Weltbild.
> Daraus ist zu schließen daß bei Dir Python höchstens unter ferner liefen> eingeordnet ist mit null Priorität.
Ich verdiene nur (auch) damit meine Brötchen. Da ich mit anderen
zusammenarbeiten muss, kommt auch sowas wie das oben genannte pybraces
natürlich nicht in Frage.
Es ist aber für mich eben nur eine Sprache, und ich muss deshalb
nicht alles daran über den grünen Klee loben. Das heißt nicht, dass
ich es deshalb nicht zuweilen sehr gern benutzen würde, je nach
Anwendungsfall halt.
Jörg W. schrieb:> Bernd K. schrieb:>>> Doch manche Sachen kann ich aus Deinen Äußerungen inferieren.>> Insbesondere kannst du irgendwas hineininterpretieren, was ich gar> nicht (so) geschrieben habe. Hauptsache, es passt in dein Weltbild.
fast wieder python-interpreter, hahahaha
scnr.
just my 2 0x20:
die AntiEinrückFraktion drückt in diesem Thread den Stolz aus, dass
sowas wie IOCCC überhaupt möglich ist.
Auch wenn Python nicht so lange wie C (+Derivate) die Programmierende
Menschheit geisselt, ein iOPyCC ist nicht geworden. (ditto f. ASM U.
FORTRAN, beides auch EinrückZwangsFormalismen)
Andere Aspekte mögen überwiegen, aber Blockmarkierung per Einrücken
gehört (auch) zu den essentiellen Faktoren.
Der sekundäre HeiligeKrieg um Schreibstil f. C-Code, inkl. dessen
Helfershelfer (indent, Editor- u. IDE-Plugins, Forumsdiskussionen
dazu, usw.) haben, tun und werden noch bis in die Ewigkeit Ressourcen
(Zeit, Hirnschmalz, Brain-Cycles, ...) überflüssigerweise verpuffen.
Bei Python konnten besagte Ressourcenanteile ins "Vowärtskommen"
investiert werden, wegen dem "Guten[TM]"-Zwang zur Einrücken. Dies hat
Python in seiner ggü. C kürzeren Existenz soweit gebracht wie es heute
ist, inkl. numpy, mathplotlib & co.
- - -
Das ist ca. Vergleichbar wie die Gross-/kleinschreibung im
Deutschschreiben: Wozu, wenns beim Aussprechen eh nicht zu hören ist?
Und keine andere Sprache (it/fr/es/en/de/hr/pt in meinem statistisch
irrelevanten Spielpark) ärgert einem damit!
Aber beim Sätzezusammenhirnen vergegenwärtigt es einem
Satzbauimplikationen, welche das Sprachebeherrschen unterstützen.
Für De-Muttersprachler ein nicht wegzudenkendes Feature; für
Polyglotten ein sonderbarer Sonderfall.
Ist der nächste Thread über Disziplin/Zwang um CamelCasing von
Identifier in Quellcode?
Obi Wahn Whitepace vs. Brace Celly schrieb:> die AntiEinrückFraktion
Gibt es die?
Keiner hat was gegen ordentlich eingerückten Code gesagt. Das einzige
Argument ist es, dass es einer Reihe von Leuten nicht gefällt, diese
zum syntaktischen Element zu machen, während andere dies bis aufs
Messer verteidigen und permanent behaupten, dass die Leute ohne diesen
Zwang ja wohl zu faul wären, es ordentlich zu tun.
Unleserlichen Code kann man noch immer in jeder Programmiersprache
verbrechen.
p.s.: Keiner hat auch je behauptet, dass Klammern die einzig mögliche
oder sinnvolle Strukturierung sind. Ruby mit seinem “end” ist genauso
praktikabel. Hilft natürlich nur nicht viel, denn es wurde ja schon
festgestellt, dass die wesentliche Stärke von Python ja vor allem in
sowas wie numpy und matplotlib und dergleichen besteht.
Jörg W. schrieb:> Keiner hat was gegen ordentlich eingerückten Code gesagt. Das einzige> Argument ist es, dass es einer Reihe von Leuten nicht gefällt, diese> zum syntaktischen Element zu machen, während andere dies bis aufs> Messer verteidigen und permanent behaupten, dass die Leute ohne diesen> Zwang ja wohl zu faul wären, es ordentlich zu tun.
Die Überbetonung der Relevanz dieser syntaktischen Eigenheit geht aber
in beide Richtungen in diesem Thread und nicht wie von dir suggeriert
nur in eine.
ja, ich hab noch eine Ergänzung:
es wird per Bähgeste immer auf Pascal wegen ihres (die Prog.Sprache,
fem.) wordyschen BEGIN/END gezeigt.
Pascal war das seinerzeit erfolgreiche "Erstlingswerk". In
Folgederivate aus der Schmiede von N. Wirth (und Andere) haben der
BEGIN/END Wordyness gegengesteuert.
Schade bleiben Modula/2, Oberon und Ada in diesem Kontext unerwähnt.
- - -
Warum unspezifische Paare, egal ob {/} oder BEGIN/END?
Folgende, bunt gemischte, Beispiele sind selbstredend:
1
if true
2
then statement, ...
3
fi #kann nur ifs abschliessen
4
5
while true
6
do
7
statement(s)
8
done # kann nur whiles abschliessen
9
10
PROCEDURE part_one(arg : CARDINAL)
11
BEGIN
12
statement;
13
:
14
FOR c IN [31, 28, 31, 30, 31]
15
DO
16
statement;
17
:
18
ENDFOR; /* kann nur FORs abschliessen */
19
END part_one; /* schliesst NUR part_one */
20
21
22
DEFINITION MODULE Kapselung;
23
:
24
END Kapselung; /* schliesst NUR Kapselung */
In solchem Code nach öffnenden/schliessenden Zeilen zu suchen ist
plötzlich (eher) mit einfachen REs möglich, nicht nötig den ganzen
Syntaxbaum nebenher mitzuverfolgen :)
Stösst ein Adacompiler auf ein Syntaxfehler, kann er in vielen Fällen,
mit hoher Trefferquote(!) die richtige Annahme über das Fehlende
treffen un den Durchlauf weiterführen.
Das Ergebnis sind viele nützliche_ weil _zutreffende
Compilerfehlermeldungen.
Bei C-Compilern sind der grosse
Teil von Folgefehlermeldungen absolut irreführen weil unpassend. Ja oft
ist nichtmal die erste Fehlermedung eines C-Compilers die des Fokus
würdigste...
just my 2 0x09...
Find' ich nicht so toll. Da eine moderne Heursitik zu haben die eine
ordentliche Fehlermeldung generiert ist Aufgabe des Compilerbauers. Und
es ist nicht soo schwer, falsch gesetzte Klammern vernünftig zu
reporten.
Die bash hat ja dieses komische fi und esac und so. Dann ist ihnen
aufgefallen, das das bei for halt rof heißen würde und bei do od und das
klingt ja blöd und deshalb ist es da anders. Super.
CMake hatte die andere Form, sogar so extrem dass man beim if() die
Bedingung nochmal wiederholen musste. if(${foo}) ... endif(${foo}).
Haben sie auch komplett gestrichen, benutzt keiner mehr.
Evtl. müssten die Menschen die sich so an der Einrückung aufhängen mal
einen anderen Editor benutzen? Wenn ich dieses Skript in Kate tippe,
muss ich kein einziges Mal Tab oder Backspace drücken:
Jörg W. schrieb:> Unleserlichen Code kann man noch immer in jeder Programmiersprache> verbrechen.
Stimmt. Aber niemand macht im Python-Biotop einen Kult draus. Auch wenn
es gelegentlich Ansätze gibt, wie etwa den nachfolgenden, der von Jeff
Preshing stammt.
>> p.s.: Keiner hat auch je behauptet, dass Klammern die einzig mögliche> oder sinnvolle Strukturierung sind.
Doch, ungefähr das hast Du behauptet. Du hältst explizite Klammern in
allen ihren syntaktischen Varianten für das Gelbe vom Ei und setzt
Strukturierung durch Einrückung fälschlich mit "significant whitespace"
gleich und lehnst die als solchen ab. Deine Meinung, Dein Bier, mehr
aber auch nicht.
<schnipp>
1
_ = (
2
255,
3
lambda
4
V ,B,c
5
:c and Y(V*V+B,B, c
6
-1)if(abs(V)<6)else
7
( 2+c-4*abs(V)**-0.4)/i
8
) ;v, x=1500,1000;C=range(v*x
9
);import struct;P=struct.pack;M,\
10
j ='<QIIHHHH',open('M.bmp','wb').write
11
for X in j('BM'+P(M,v*x*3+26,26,12,v,x,1,24))or C:
Es ist schon erstaunlich wie hier einige versuchen offensichtliche
Designschwächen in Python schön zu reden.
Natürlich ist es für gut leserlichen Code unabdingbar eine passende
Struktur zu finden, die für das menschliche Auge auch gut erkennbar ist.
Ja und da sind sich auch alle hier einig das da Einrückungen eine gute
Wahl sind, da für das menschliche Auge gut erkennbar.
Aber Einrückungen als Blockkennzeichnung zu benutzen halte ich auch für
problematisch, wenn auch machbar. Das das nicht so dolle ist hat ja
schon das angesprochene make bewiesen. Fakt ist das ich in langen
Quelltexten eine Einrückung um nur ein Leerzeichen schlecht erkenne.
Wenn mir das passiert kann ich in Python durchaus ein Problem haben und
kein Parser kann mir da helfen, weil eine Einrückung in Python ein
Sprachkonstrukt ist. Das einzige was mir hier hilft ist evtl. ein diff,
wenn ich im Besitz einer früheren Version bin.
Das heißt jetzt nicht das Python generell schlecht ist. Es ist wie bei
allem, es hat Vor- und Nachteile. Vorteil ist in jedem Fall das der
Programmierer zu einer ordentlichen Strukturierung des Quelltextes
gezwungen wird. Ob der Text dann für jeden besser lesbar ist sei mal
dahin gestellt. Letztendlich muß ich den (fremden) Quelltext immer
durcharbeiten, um ihn zu verstehen und dazu muß ich mich letztendlich in
die Denkweise der Programmieres versetzen.
Das Argument das ich dabei Schreibarbeit spare ist Quark. Es ist völlig
egal ob ich Tab, Space oder { eingebe.
Ich persönlich bevorzuge auch eine eindeutige Klammerung von
funktionalen Blöcken mit { und } oder begin / end (letzeres ist für mich
am eindeutigsten und für jeden les- und verstehbar). Ich mache
mittlerweile auch Blöcke, wo es eigentlich nicht erforderlich ist.
Beispiel:
if a=1 then b:=0;
schreibe ich immer so:
if a=1 then
begin
b:=0;
end;
Beides in Pascal zulässig aber die Variante 2 hat für mich Vorteile:
1. Ich kann den Block jederzeit um mehrere Anweisungen /Blöcke erweitern
2. Falls aus irgend einem Grund das if-Statement nicht mehr erforderlich
sein sollte, kann ich es einfach auskommentieren.
Das mag zwar jetzt eine persönliche Eigenart von mir sein, aber ich
komme damit sehr gut zu recht.
Letzendlich ist es aber jedem selbst überlassen, wie er seinen Quelltext
formatiert. Wichtig ist nur das er formatiert / strukturiert wird und
das das Formatierungsschema konsequent eingehalten wird. Dann wird jeder
der diesen Quelltext lesen möchte ihn auch lesen können.
Ansonsten bin ich schon eher bei Jörg und W.S. die eine Blockbildung mit
lesbaren Kennzeichnern für besser halten.
@Sven:
Also das
>Ich sehe ehrlich gesagt keinen großen Hype um Python. Die Bibliotheken>(insb. numpy!) sind halt einfach konkurrenzlos gut, ich kenne keine>Sprache mit was vergleichbarem ...
ist eine sehr gewagte Aussage - um es mal vorsichtig zu formulieren.
Ersten war es nicht das Thema ob es gute Bibliotheken in Python gibt
oder nicht. Zweitens ist dann das was Du als Beispiel aufführst:
> Sven B. schrieb:>> data = np.loadtxt("foo.csv")>> plt.plot(np.abs(np.fft.rfft(data))>>
kein Teil des Sprachumfanges von Python sondern eben nur eine
Bibliothek, welche natürlich in Python geschrieben ist. Das heißt es hat
sich mal einer hingesetzt und einen komplexen Ablauf in einem Objekt mit
Methoden gekapselt. Ja und natürlich ist es dann einfacher Aufgaben zu
lösen wenn man derartige Objekte oder Bibliotheksfunktionen nutzt bzw.
nutzen kann.
Das Bibliothekskonzept ist aber nun keine Erfindung von Python. Das gibt
es schon lange bei z.B. Fortran und Pascal. Speziell bei Pascal wird
auch rege davon Gebrauch gemacht. Und selbstverständlich kann man mit
Pascal hervorragend mathematische Probleme aller Art lösen. Ich selbst
nutze Pascal für astronomische Berechnungen und da wird viel und komplex
gerechnet. Und ja die meisten immer wieder kehrenden Funktionen sind in
Bibliotheken hinterlegt (z.B. Matrizenberechnungen). Und wenn es auf
Geschwindigkeit ankommt, dann ist immer noch Fortran eine gute Wahl für
mathematische Probleme.
Gruß Zeno
Zeno schrieb:> kein Teil des Sprachumfanges von Python sondern eben nur eine> Bibliothek, welche natürlich in Python geschrieben ist. Das heißt es hat> sich mal einer hingesetzt und einen komplexen Ablauf in einem Objekt mit> Methoden gekapselt. Ja und natürlich ist es dann einfacher Aufgaben zu> lösen wenn man derartige Objekte oder Bibliotheksfunktionen nutzt bzw.> nutzen kann.> Das Bibliothekskonzept ist aber nun keine Erfindung von Python. Das gibt> es schon lange bei z.B. Fortran und Pascal.
Jaja. Aber: Interessiert mich nicht. Ich benutz Python nicht aus
ideologischer Überzeugung, sondern weil ich schnell und komfortabel
meine Probleme damit lösen kann. Ob das an der Sprache liegt oder an den
Bibliotheken, die es für die Sprache gibt, ist mir egal.
Mmn. ist die Syntax von so einer Sprache ziemlich egal. Es kommt auf das
Ökosystem und die Tools an. Das stört mich auch an den ganzen neuen
Hipster-Sprachen; ja, mag ja sein, dass die Sprache schöner ist, aber
lohnt es sich dafür, das ganze Ökosystem umzubauen? Meistens eher nicht.
So viel Gewinn ist da nicht drin.
> Speziell bei Pascal wird> auch rege davon Gebrauch gemacht. Und selbstverständlich kann man mit> Pascal hervorragend mathematische Probleme aller Art lösen. Ich selbst> nutze Pascal für astronomische Berechnungen und da wird viel und komplex> gerechnet.
Bitte, wenn du damit gut zurecht kommst, ist doch prima. Ich habe ja
nicht gesagt "es gibt nichts", ich habe gesagt "ich kenne nichts". Mir
ist bisher nichts begegnet, womit ich komfortabler Daten verarbeiten
kann als mit Python/numpy/matplotlib. Ich lasse mir gern was besseres
zeigen. Aber da da ein großer Gewöhnungseffekt dabei ist, muss das schon
deutlich besser sein, damit ich tatsächlich umsteige.
Zum Teil ist das sicher alles auch einfach persönliche Präferenz.
Hier von "offensichtlichen Designschwächen" zu reden ist m.E. einfach
albern. Man gewöhnt sich vergleichsweise schnell an die Syntax einer
Sprache, und danach ist die relativ egal. In diesem Thread sehe ich
hauptsächlich Beiträge die sagen "ICH BENUTZE PYTHON DEN GANZEN TAG UND
DIE SACHE MIT DER EINRÜCKUNG IST TOTAL TOLL" und die anderen die sagen
"ICH BENUTZE DEN GANZEN TAG WAS ANDERES UND JETZT MUSS ICH PYTHON
SCHREIBEN UND DIE EINRÜCKUNG NERVT". Meh. Die meisten Menschen kommen
gut mit dem zurecht was sie gewohnt sind und manche Arbeitsweisen passen
nicht zu manchen Leuten. Toller Erkenntnisgewinn.
Bernd K. schrieb:> Jeder der Python regelmäßig verwendet liebt die Blockbildung durch> Einrückung und den damit einhergehenden Wegfall der lästigen redundanten> Klammern.
Ich benutz Python an 4/5 Arbeitstagen und manchmal privat. Außerdem hab
ich bei uns viele lästige Routinearbeit mit Python automatisiert. Ist
das regelmäßig genug?
Und ich gehör zu zu den Einrückungskritikern.
Tja, Pauschalaussagen sind so einfach zu widerlegen...
Klammern sind doch ned lästig. Einmal gesetzt passt der geklammerte
Block bis zum Sanktnimmerleinstag.
Bei Python muss ich bei Copy/paste IMMER einrücken, außer die Ebene
passt zufällig.
Zumindest drüber sehen und kontrollieren muss ich aber immer.
Und um nichts anderes gehts doch Jörg und mir. Aber ich kau ned alles
nochmal durch, irgendwie riechts hier nach Fanboytum gepaart mit
gerechter Nerdrage.
Was solls, nach ein paar Sprachen sieht man das lockerer. Da muss man
nix mehr sinnlos verteidigen sondern kann auch mal bestimmte
Sprachkonstrukte kritisieren, die Sprache aufgrund anderer Vorzüge aber
dennoch benutzen.
Mahlzeit!
le x. schrieb:> Was solls, nach ein paar Sprachen sieht man das lockerer. Da muss man> nix mehr sinnlos verteidigen sondern kann auch mal bestimmte> Sprachkonstrukte kritisieren, die Sprache aufgrund anderer Vorzüge aber> dennoch benutzen.
Ganz genauso sehe ich das auch.
Btw., ich habe auch nie was gegen Pascal gehabt. Es war mir eine
ungeheuere Erleichterung unter CP/M, damit statt in Assembler
programmieren zu können, und Turbo-Pascal machte dazumals seinem
Namen alle Ehre. Dass es etwas wortreicher ist als C, hat mich dabei
nie gestört, ich kann eh' schnell genug tippen.
Allerdings hat eben auch Pascal seine Schwächen (genau wie C oder Perl),
und auch aus denen habe ich nie einen Hehl gemacht.
Natürlich hat jede (Programmier) Sprache Stärken und Schwächen - das
liegt einfach in der Natur der Sache.
Selbstverständlich ist auch in Pascal nicht alles gut. Habe ich ja auch
nicht behauptet. Aber mir geht es ähnlich wie Jörg ich habe seinerzeit
mit Turbopascal angefangen und mir autodidaktisch programmieren
beigebracht. Und damals war halt Turbopascal das Maß der Dinge. Borland
hatte halt eine IDE geschrieben, die auch für Anfänger gut zu gebrauchen
war. Dem Hilfesystem von Turbopascal weine ich heute noch hinter her -
das war Spitze. Bis Delphi 4 ging es ja noch aber dann ging es speziell
mit dem Hilfesystem Berg ab, um nicht zu sagen nicht mehr zu gebrauchen.
Aber das war eigentlich nicht gefragt, deshalb zurück zum Thema. Es ging
um Einrückungen als blockbildentes Element. Und da bin ich halt der
Meinung, das dies nicht der optimale Weg ist und schon Quelle für schwer
zu lokalisierende Fehler ist. Und das läßt sich halt auch nicht mit so
tollen Features, Bibliotheken etc. schön reden.
Dennoch finde ich Python nicht schlecht und das Eine oder Andere mache
ich auch damit. Es kommt halt immer darauf an was ich erreichen möchte.
Es gibt keine Programmiersprache mit der ich alle Probleme gleich gut
lösen kann.
Trotz aller Bedenken Einrückungen als sprachliches Konstrukt zu
verwenden, halte ich Python für Anfänger für gar nicht so schlecht, da
sie so gezwungen werden lesbaren oder besser formatierten Code zu
schreiben. Die schreiben aber i.d.R. eher kleinere überschaubare
Programme.
Ein Programm mit knapp 200000 Zeilen möchte ich nicht mit Python
schreiben, da sind zu viele falsch eingerückte Zeilen vorprogrammiert
und da hilft auch kein Debugger, weil er eine falsch eingerückte Zeile
nicht als Fehler erkennen kann - es gehört halt zum Feature der Sprache.
Ich selbst bin auch in die Falle getappt, weil ich in einer Zeile ein
Leerzeichen zu viel hatte und habe ewig gesucht, weil man es eben nicht
auf 6m erkennt wie manche behaupten, der Interpreter aber schon.
Zeno
Hä, aber der Interpreter motzt dann doch. Der streicht dir genau die
Zeile an und sagt "Unexpected Indentation". Mir ist total unklar, wie
das ein Problem sein kann.
Blöcke ... naja. Ich hatte auch schon in C++ Code wo Sachen im falschen
Block waren versehentlich ... oder, andersrum, wo die Klammer gestimmt
hat und ich ihn falsch gelesen habe weil er falsch eingerückt war.
Lesestoff zum Thema:
http://www.secnetix.de/olli/Python/block_indentation.hawk
Wurde in diesem Thread zwar alles schon mal angesprochen und i.W.
ignoriert, aber da ist es jedenfalls schön kompakt zusammengefasst. Nur
für den Fall, daß jemand mal tatsächlich argumentieren statt bloß
weitschweifig seinen Gefühlen Ausdruck verleihen möchte. :-}
Sven B. schrieb:> Hä, aber der Interpreter motzt dann doch. Der streicht dir genau die> Zeile an und sagt "Unexpected Indentation". Mir ist total unklar, wie> das ein Problem sein kann.
Aber nur wenn's eineindeutig ist. Hier würde der Interpreter meckern:
1
ifi<3
2
print"1"
3
print"2"
4
print"3"
Hier nicht:
1
ifi<3
2
print"1"
3
print"2"
4
print"3"
Hier auch nicht und das ist was ich will:
1
ifi<3
2
print"1"
3
print"2"
4
print"3"
Wenn ich jetzt versehentlich 2 geschrieben habe aber 3 möchte suche ich
mir einen Wolf wenn's umfangreicher wird.
Bei Pascal oder auch C meckert der Compiler wenn ich das schließende end
oder die } vergesse.
Gut falsch setzen kann die schließenden Tags immer noch, aber ich finde
das fällt eher auf - mir geht es jedenfalls so. Allerdings passiert es
bei modernen Editoren eher selten, da sie nach dem öffnenden Tag sofort
den schließenden in einer neuen Zeile setzen.
Was ich in Python überhaupt nicht machen kann sind Böcke zur besseren
Strukturierung bzw. wenn ich Quelltextteile besonders hervorheben
möchte. Z.B.:
Anweisung 1
Anweisung 2
Anweisung 3
Anweisung 4
Anweisung 5
Anweisung 6
Im Beispiel möchte ich die Zeilen mit den Anweisungen 4 und 5 besonders
hervorheben. Geht in Python nicht in Pascal, C etc. sehr wohl, da dort
Einrückungen keine syntaktische Bedeutung haben. Ich könnte in Pascal
das sogar so schreiben:
Anweisung 1;
Anweisung 2;
Anweisung 3;
begin
Anweisung 4;
Anweisung 5;
end;
Anweisung 6;
Natürlich hat diese Klammerung keine syntaktische Bedeutung und wird vom
Compiler einfach weg optimiert, aber für die Lesbarkeit/Kennzeichnung
extrem vorteilhaft.
Aber vielleicht geht ja so was auch in Python und ich bin nur zu blöd
dazu, lasse mich aber gern eines besseren belehren - komm jetzt aber
nicht mit Kommentaren, das meine ich nicht
Zeno
Zeno schrieb:> Natürlich hat diese Klammerung keine syntaktische Bedeutung und wird vom> Compiler einfach weg optimiert, aber für die Lesbarkeit/Kennzeichnung> extrem vorteilhaft.
Das ist in C absolut nicht so, und deshalb würde ich so eingerückten
Code auch absolut nicht haben wollen.
Sven B. schrieb:> Zeno schrieb:>> Natürlich hat diese Klammerung keine syntaktische Bedeutung und wird vom>> Compiler einfach weg optimiert, aber für die Lesbarkeit/Kennzeichnung>> extrem vorteilhaft.> Das ist in C absolut nicht so, und deshalb würde ich so eingerückten> Code auch absolut nicht haben wollen.
Du hast es nicht verstanden oder willst es nicht verstehen. Es dient der
besseren Hervorhebung von speziellen Quelltextpassagen und das macht in
sehr großen Projekten durchaus Sinn, insbesondere dann, wenn man auch
nach 5 Jahren das Programmkonzept noch einmal nachvollziehen möchte/muß.
Übrigens funktioniert das auch in C - habe ich gerade noch mal
ausprobiert.
Ob Du Deinen Quelltext nun in dieser Art und Weise strukturierst bleibt
Dir überlassen - es zwingt Dich keiner dazu, mal abgesehen davon das es
in Python nicht möglich ist. Mir war es des Öfteren schon eine Hilfe.
Ebenso benutze ich für temporären Code, also Code den ich nur zu
Testzwecken/Fehlersuche einfüge gern "Ausrückungen", da sich diese
schnell wieder finden lassen, um sie zu löschen. Ausrückungen beginnen
bei mir immer in der 1.Textspalte, während der restliche Code generell
Minimum 2 Spaces eingerückt ist also frühestens in Spalte 3 beginnt.
Aber jeder mag seinen Quelltext so formatieren, wie es ihm beliebt.
Wichtig ist halt nur das man seine Formatierung konsequent durchhält.
Bei Python bin ich in meiner Formatentscheidung eben nicht frei, da hier
Einrückungen Teil des Sprachkonzepts sind.
Zeno
Zeno schrieb:> Du hast es nicht verstanden oder willst es nicht verstehen. Es dient der> besseren Hervorhebung von speziellen Quelltextpassagen und das macht in> sehr großen Projekten durchaus Sinn, insbesondere dann, wenn man auch> nach 5 Jahren das Programmkonzept noch einmal nachvollziehen möchte/muß.>> Übrigens funktioniert das auch in C - habe ich gerade noch mal> ausprobiert.
Wenn du in C oder C++ Klammern setzt kriegst du anderen Code. Das
beginnt ein Scope, und das kann diverse Bedeutungen haben. Gerade in C++
wird der "irgendwas passiert, solange ein Objekt auf dem Stack
liegt"-Pattern immer verbreiteter, und dafür sind die Klammern
fundamental. Ein typisches Beispiel ist eine MutexLocker-Klasse.
Deshalb sollte m.E. auch unbedingt die Einrückung zur Blockstruktur
passen.
Einrückung ist keine sinnvolle Hervorhebung für Codepassagen, denn sonst
erreichst du genau das umgekehrt, worüber alle bei Python klagen: Ich
schaue auf den Code, denke da endet ein Scope (und es wird z.B. ein Lock
released), das ist aber gar nicht so, weil nur die Einrückung da ist
aber nicht die Klammer.
> Mir war es des Öfteren schon eine Hilfe.> Ebenso benutze ich für temporären Code, also Code den ich nur zu> Testzwecken/Fehlersuche einfüge gern "Ausrückungen", da sich diese> schnell wieder finden lassen, um sie zu löschen.
Sowas gehört als Feature in den Editor ("Bookmark" o.ä.).