Forum: PC-Programmierung Einrückung in Python


von bal (Gast)


Lesenswert?

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.

: Gesperrt durch Moderator
von Eric B. (beric)


Lesenswert?

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

von vimperator (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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 …

von Salewski (Gast)


Lesenswert?

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.

von guestono (Gast)


Lesenswert?

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.

von Po (Gast)


Lesenswert?

Schreib dir einen precompiler der deine Syntax in die andere umwandelt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.)

von vimperator (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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

von bal (Gast)


Lesenswert?

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.

von Alabama J. (alabamajack)


Lesenswert?

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ß :)

von Kaj (Gast)


Lesenswert?

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
int mein(void)
2
{
3
int a, b, c=0xDeadBeef;
4
unsigned int d[10][10];
5
for(a=0; a<10; a++)
6
for(b=0; b<10; b++)
7
d[a][b]=c;
8
return 0;
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
    goto fail;
3
  goto fail;
4
  if( any_other )
5
    goto fail;
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.

von bal (Gast)


Lesenswert?

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.

von PittyJ (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Salewski, Stefan (Gast)


Lesenswert?

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.

von Salewski, Stefan (Gast)


Lesenswert?

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.

von gandalf (Gast)


Lesenswert?

bal schrieb:
> Jetzt gebt mir Tiernamen

Schmetterling

von Yalu X. (yalu) (Moderator)


Lesenswert?

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 ;-)).

von Salewski, Stefan (Gast)


Lesenswert?

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)

von Sven B. (scummos)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

Salewski, Stefan schrieb:
> nur mit Python2 funktioniert?

/ vs. //
?

von Salewski, Stefan (Gast)


Lesenswert?

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.

von Salewski, Stefan (Gast)


Lesenswert?

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!

von Sven B. (scummos)


Lesenswert?

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 :-)

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Salewski, Stefan (Gast)


Lesenswert?

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.

von root (Gast)


Lesenswert?

https://www.youtube.com/watch?v=eVChXmNjV7o
what python can learn from haskell

wird für paar Leute interessant sein ;-)

von bal (Gast)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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:

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
——————————————————————————
[/offtopic]

von Kaj (Gast)


Lesenswert?

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

von Norbert (Gast)


Lesenswert?

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:
1
             int    float
2
——————————————————————————
3
Python 3   7.190s   7.120s
4
——————————————————————————

von Norbert (Gast)


Angehängte Dateien:

Lesenswert?

Ups, code vergessen...

von Yalu X. (yalu) (Moderator)


Lesenswert?

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 :)

von nicht"Gast" (Gast)


Lesenswert?

bal schrieb:
> Jetzt gebt mir Tiernamen

Hasi

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
  else blubb;

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“.

von vimperator (Gast)


Lesenswert?

Jörg Wunsch schrieb:
> Davon abgesehen, wäre ein einfaches if/else in C noch kompakter ;-)

Nein.
1
if a: bla
2
else: blubb

von vimperator (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

vimperator schrieb:
> Jörg Wunsch schrieb:
>> Davon abgesehen, wäre ein einfaches if/else in C noch kompakter ;-)
>
> Nein.
>
>
1
> if a: bla
2
> else: blubb
3
>

Ah ja, stimmt.  Eine von Pythons Inkonsistenzen.  Normalerweise
eine Anweisung pro Zeile, aber dort plötzlich nicht.

von Stefan Salewski (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

: Bearbeitet durch User
von vimperator (Gast)


Lesenswert?

Sven B. schrieb:
> Das sind aber alles keine Statements, sondern Expressions

http://www.duden.de/rechtschreibung/scheinbar_imaginaer_vermeintlich

von W.S. (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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:

1
    Python with Braces                             |    Python
2
——————————————————————————————————————————————————————————————————————————————————————————————————————
3
                                                   |
4
    def ggT(a, b)                                  |    def ggT(a, b):
5
    {                                              |      while b:
6
      while b                                      |        a, b = b, a % b
7
      {                                            |      return a
8
        a, b = b, a % b;                           |
9
      }                                            |    def main():
10
      return a;                                    |      try:
11
    }                                              |        z1 = input('1. Zahl: ')
12
                                                   |        z2 = input('2. Zahl: ')
13
    def main()                                     |        z = ggT(z1, z2)
14
    {                                              |      except:
15
      try                                          |        print 'Fehler'
16
      {                                            |      else:
17
        z1 = input('1. Zahl: ');                   |        print 'ggT(%d, %d) = %d' % (z1, z2, z)
18
        z2 = input('2. Zahl: ');                   |
19
        z = ggT(z1, z2);                           |    main()
20
      }                                            |
21
      except Exception                             |
22
      {                                            |
23
        print 'Fehler';                            |
24
      }                                            |
25
      else                                         |
26
      {                                            |
27
        print 'ggT(%d, %d) = %d' % (z1, z2, z);    |
28
      }                                            |
29
    }                                              |
30
                                                   |
31
    main();                                        |
32
                                                   |
33
——————————————————————————————————————————————————————————————————————————————————————————————————————

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 ;-)

von Salewski (Gast)


Lesenswert?

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.

von unechter Python-Programmierer (Gast)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von unechter Python-Programmierer (Gast)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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 ;-)

von Markus (Gast)


Lesenswert?

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

von klausro (Gast)


Lesenswert?

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

von unechter Python-Programmierer (Gast)


Lesenswert?

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).

von Sven B. (scummos)


Lesenswert?

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.

: Bearbeitet durch User
von Rolf M. (rmagnus)


Lesenswert?

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.

von bal (Gast)


Lesenswert?

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 :-)

von Sven B. (scummos)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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?

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.html

Sven 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
1
  s = ''.join([s1, s2, s3])

oder mit einem Komma als Trennstring
1
  s = ','.join([s1, s2, s3])

Das sieht doch ziemlich wirr aus. Wieso nicht
1
  s = join([s1, s2, s3])

mit optionalem Argument für den Trennstring
1
  s = join([s1, s2, s3], ',')
?

: Bearbeitet durch Moderator
von Stefan Salewski (Gast)


Lesenswert?

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.

http://build.nimrod-lang.org/docs/manual.html#method-call-syntax

http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394

von vimperator (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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 ;)

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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".

: Bearbeitet durch User
von Micha S. (ernie)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

Nachtrag: umfänglich und ebenso

von Bernd K. (prof7bit)


Lesenswert?

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.

: Bearbeitet durch User
von Sven B. (scummos)


Lesenswert?

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

von Micha S. (ernie)


Lesenswert?

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

von Sven B. (scummos)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Angehängte Dateien:

Lesenswert?

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.

von Vlad T. (vlad_tepesch)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Michael (Gast)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Rolf Magnus (Gast)


Lesenswert?

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.

von unechter Python-Programmierer (Gast)


Lesenswert?

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

von Mehmet K. (mkmk)


Lesenswert?

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.

: Bearbeitet durch User
von unechter Python-Programmierer (Gast)


Lesenswert?

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?

von Bernd K. (prof7bit)


Lesenswert?

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!)

von unechter Python-Programmierer (Gast)


Lesenswert?

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.

von Rolf Magnus (Gast)


Lesenswert?

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?

von Rolf Magnus (Gast)


Lesenswert?

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.

von Vlad T. (vlad_tepesch)


Lesenswert?

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).
1
  code
2
  code 
3
  
4
  {
5
    int someTemp;
6
    code
7
  }
8
9
  {
10
    float someTemp;
11
    code
12
  }

Das geht in Python imho nicht.

: Bearbeitet durch User
von Kaj (Gast)


Lesenswert?

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!

von Vlad T. (vlad_tepesch)


Lesenswert?

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.

von unechter Python-Programmierer (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

von pc_oldie (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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 …)

von vimperator (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Michael K. (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

Yalu X. schrieb:
> keinerlei Inkompatibiltäten verursacht.

außer, dass Zeilennummern nicht mehr stimmen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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"...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. ;)

von Vlad T. (vlad_tepesch)


Lesenswert?

@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
  more code ...
6
}

Ich find es ziemlich schwer, so den Überblick zu behalten, wo die 
Bedingung aufhört und der Code anfängt.

Da bevorzuge ich:
1
if(   (something == -1) 
2
   && (somethingelse == -1) 
3
   && (etc == -1) ) 
4
{
5
  code;
6
  more code ...
7
}

von Vorschau (Gast)


Lesenswert?

Und in Ruby
1
if something == -1 && somethingelse == -1 && etc == -1 
2
  code
3
  more code ...
4
end

Und in Python/Nim vermutlich
1
if something == -1 and somethingelse == -1 and etc == -1:
2
  code
3
  more code ...

von Yalu X. (yalu) (Moderator)


Lesenswert?

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
  more code ...
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:
1
if bedingung then begin
2
  :
3
  :
4
end

: Bearbeitet durch Moderator
von Yalu X. (yalu) (Moderator)


Lesenswert?

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 :)

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von vimperator (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

vimperator schrieb:
> Gerade das ist in C ja auch erst seit "kurzem" (C99) möglich.

Nein, das gibt's seit dem Ur-C.

von vimperator (Gast)


Lesenswert?

nein
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
Anscheinend ist es sogar eine gcc-extension und in gar keinem 
C-Standard.

von Felix (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Benji (Gast)


Lesenswert?

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!

von Karl (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Senior Scheffentwickler (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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 ;)

: Bearbeitet durch User
von Bernd (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

: Bearbeitet durch User
von Le X. (lex_91)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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

von Wolfgang S. (ws01)


Lesenswert?

Bernd schrieb:
> 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.

Darf ich auch mal:

http://www.nature.com/news/interactive-notebooks-sharing-the-code-1.16261

http://www.nature.com/news/ipython-interactive-demo-7.21492?article=1.16261

http://www.sagemath.org/

https://cloud.sagemath.com/projects

Das obige nature-Notebook nach Sagemath übertragen:

https://cloud.sagemath.com/projects/7880d686-bf3f-4ab0-8fdd-9201dc8d7547/files/Nature.html

Und noch eins

https://cloud.sagemath.com/projects/7880d686-bf3f-4ab0-8fdd-9201dc8d7547/files/02_energy_minimization.html

Eine Sage-VM starte ich hier @home bedarfsweise auf dem kleinen 
Allzweckserver.

Für meine eher bescheidenen Zwecke und offline bzw. mobil benutze ich 
meist aber Jupyter Notebook:
http://jupyter.org/.

Das läßt sich mühelos auf div. Weisen auch ohne VM installieren.
Siehe http://jupyter.readthedocs.org/en/latest/install.html

Ein Vorteil für Sprachphobiker ist, daß das zwar in Python geschrieben 
ist und natürlich die meisten Python-basierten 
Scientific-Computing-Pakete unterstützt, aber eben auch viele andere 
Sprachen. Zitat

"Open source, interactive data science and scientific computing across 
over 40 programming languages."

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. :-)

von Le X. (lex_91)


Lesenswert?

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.

: Bearbeitet durch User
von Sven B. (scummos)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Wolfgang S. (ws01)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
     return ERROR;
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.

von ach naja (Gast)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Wolfgang S. (ws01)


Lesenswert?

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
>      return ERROR;
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. :-}

von Bernd K. (prof7bit)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Bernd K. (prof7bit)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Wolfgang S. (ws01)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

Ich empfehle an der Stelle einfach mal komplett unvoreingenommen 
KDevelop mit dem Python-Plugin.

von Tom (Gast)


Lesenswert?

Wer soviele Zeilen auf soviele Einrückungsebenen verteilt, dass die 
Übersicht verlorengeht, ist bei Python wahrscheinlich falsch.

von Sven B. (scummos)


Lesenswert?

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. ;)

von Stefan Salewski (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

Make übrigens auch, da hat noch keiner gemotzt ;)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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 …

von Mark B. (markbrandis)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

1
from __future__ import braces

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

1
SyntaxError: not a chance

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?


von Sven B. (scummos)


Lesenswert?

oh gott

von Bernd (Gast)


Lesenswert?

Sven B. schrieb:
> oh gott

Was gibt es mein Sohn? Python wird doch nur erwachsen.

von Fer T. (fer_t)


Lesenswert?

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.

von mad 4. (mad474)


Lesenswert?

pybraces.bookmark() :D

von Eric B. (beric)


Lesenswert?

mad 4. schrieb:
> pybraces.bookmark() :D

Falsch rum: bookmarks.add(pybraces) ;-)

von Decius (Gast)


Lesenswert?

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

von Decius (Gast)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

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.

von schpock (Gast)


Lesenswert?

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

von Dieter F. (Gast)


Lesenswert?

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 :)

von ach naja (Gast)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

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.

von Obi Wahn Whitepace vs. Brace Celly (Gast)


Lesenswert?

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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

: Bearbeitet durch Moderator
von Sven B. (scummos)


Lesenswert?

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.

von Obi Wahn Whitepace vs. Brace Celly (Gast)


Lesenswert?

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

von Sven B. (scummos)


Lesenswert?

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:
1
import numpy as np
2
import matplotlib.pyplot as plt
3
4
def f(x, a):
5
    if (a < 0).any():
6
        raise ValueError("a < 0")
7
    return x**a
8
9
x = np.arange(100)
10
plt.plot(x, f(x, 2.3))

: Bearbeitet durch User
von Wolfgang S. (ws01)


Angehängte Dateien:

Lesenswert?

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:
12
            i  ,Y=_;j(P('BBB',*(lambda T:(T*80+T**9
13
                  *i-950*T  **99,T*70-880*T**18+701*
14
                 T  **9     ,T*i**(1-T**45*2)))(sum(
15
               [              Y(0,(A%3/3.+X%v+(X/v+
16
                               A/3/3.-x/2)/1j)*2.5
17
                             /x   -2.7,i)**2 for  \
18
                               A       in C
19
                                      [:9]])
20
                                        /9)
21
                                       )   )

Dass man auch kompakt und leserlich schreiben kann, sieht man an 
folgendem Beispiel:

https://github.com/thomasahle/sunfish

von Zeno (Gast)


Lesenswert?

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

von Sven B. (scummos)


Lesenswert?

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.

: Bearbeitet durch User
von Le X. (lex_91)


Lesenswert?

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!

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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

von Sven B. (scummos)


Lesenswert?

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.

von Wolfgang S. (ws01)


Lesenswert?

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. :-}

von Zeno (Gast)


Lesenswert?

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
if i<3
2
 print "1"
3
print "2"
4
 print "3"

Hier nicht:
1
if i<3
2
 print "1"
3
 print "2"
4
 print "3"

Hier auch nicht und das ist was ich will:
1
if i<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

von Sven B. (scummos)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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

von Sven B. (scummos)


Lesenswert?

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.ä.).

: Bearbeitet durch User
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.