Würfeln mit Armin

Rainer Weikusat

unread,

Apr 7, 2021, 7:54:21 AM4/7/21

to

Perl-Implementierung eines auf Facebook veröffentlichten Algorithmus'
zur Ermittlung von Armin Laschets Forderungen zur Corona-Politik.

NB: Ich habe mir das gestern mal schnell geschrieben, weil ich die Idee
witzig fand ohne mir groß Gedanken darüber zu machen, wie sinnvoll oder
verständlich der Code ist.

«Was wir jetzt brauchen ist ein vierhebiger intransparenter Ehrenstopp
bis in die Puppen zur sofortigen Halbierung der Bundesklanzlerin.»

----------
#!/usr/bin/perl
#
# "wuerfeln mit Armin"
#

use utf8;
use open qw(:std :utf8);

my @steps = (
'Was wir jetzt brauchen ist ein/e',
['ein-', 'zwei-', 'drei-', 'vier-', 'fünf-', 'sechs-'],
[qw(tägige/r wöchige/r monatige/r fache/r malige/r hebige/r)],
[qw(harte/r softe/r optionale/r intransparente/r alternativelose/r unumkehrbare/r)],
[qw(Wellenbrecher- Brücken- Treppen- Wende- Impf- Ehren-)],
[qw(Lockdown:m Stopp:m Maßnahme:w Kampagne:w Sprint:m Matrix:w)],
'bis',
['zum Sommer', 'auf Weiteres', 'zur Bundestagswahl', '2030', 'nach den Abiturprüfungen', 'in die Puppen'],
'zur',
[qw(sofortigen nachhaltigen allmählichen unausweichlichen wirtschaftsschonenden willkürlichen)],
[qw(Senkung Steigerung Beendigung Halbierung Vernichtung Beschönigung)],
'der',
['Infektionszahlen', 'privaten Treffen', 'Wirtschaftsleistung', 'Wahlprognosen', 'dritten Welle', 'Bundesklanzlerin']);

sub roll
{
return int(rand(6));
}

sub step
{
my $step;

$step = $steps[$_];
return ref($step) ? $$step[roll()] : $step;
}

sub cnct
{
my ($last, @out);

for (@_) {
if (/(.+)-$/) {
$last .= $1;
next;
}

$_ = $last.lcfirst($_) if $last;

push(@out, $_);
$last = undef;
}

return @out;
}

sub mw
{
my (@mw, @out);

for (@_) {
if (/(.+\/(e|r))/) {
push(@out, $1);
push(@mw, $#out);

next;
}

if (/(.+):(m|w)$/) {
push(@out, $1);

if ($2 eq 'm') {
for (@mw) {
$out[$_] =~ s/\/e$//;
$out[$_] =~ s/\/r$/r/;
}
} else {
for (@mw) {
$out[$_] =~ s/\/e$/e/;
$out[$_] =~ s/\/r$//;
}
}

@mw = ();

next;
}

push(@out, $_);
}

return @out;
}

my @prg = mw(cnct(map { &step } 0 .. $#steps));

print(join(' ', @prg), ".\n");

Christian Hanné

unread,

Apr 7, 2021, 12:10:23 PM4/7/21

to

Perl is out, Pyhton ist angesagt.

Rainer Weikusat

unread,

Apr 7, 2021, 12:42:03 PM4/7/21

to

Christian Hanné <the....@gmail.com> writes:
> Perl is out, Pyhton ist angesagt.

Python ist was für Legastheniker :-)

Thomas Zajic

unread,

Apr 8, 2021, 11:30:03 PM4/8/21

to

* Rainer Weikusat <rwei...@talktalk.net>

> Christian Hanné <the....@gmail.com> writes:
> > Perl is out, Pyhton ist angesagt.
>
> Python ist was für Legastheniker :-)

Nein, das verwechselst du jetzt mit Phyton. Oder war das Pytohn? :-P
--
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic <zla...@gmx.at> Linux-5.10 & slrn-1.0.2 -
=-------------------------------------------------------------------------=

Christian Schumacher

unread,

Apr 9, 2021, 11:21:03 AM4/9/21

to

Thomas Zajic schrieb:

| User-Agent: slrn/1.0.3 (Linux)

> --
> [...] Linux-5.10 & slrn-1.0.2 -

Deine Sig braucht ein Update ;-)

--
Gruß
Christian

»Ausnahmen beschädigen die Regel.«

Thomas Zajic

unread,

Apr 11, 2021, 7:00:05 AM4/11/21

to

* Christian Schumacher <cs....@nurfuerspam.de>

> Deine Sig braucht ein Update ;-)

Oops, hoppla, danke für den Hinweis! Wie konnte *das* denn nur passieren?
Liegt bestimmt an dieser schwindelerregenden Releasefrequenz, kein Wunder
daß man da mit dem Updaten der Signatur nicht mehr hinterherkommt ... :-D

> slrn-1.0.3a.tar.bz2, creation date: 2016-10-24T09:12:38 [GMT]
> old/slrn-1.0.2.tar.bz2, creation date: 2014-09-20T02:12:26 [GMT]

(von http://jedsoft.org/releases/slrn/)

LG,
Tho "look mum, new signature!" mas
--
=-------------------------------------------------------------------------=
- Thomas "ZlatkO" Zajic <zla...@gmx.at> Linux-5.10 & slrn-1.0.3 -
=-------------------------------------------------------------------------=

Juergen Ilse

unread,

Apr 11, 2021, 5:01:02 PM4/11/21

to

Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
(sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
wieder eingefuehrt ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

Rainer Weikusat

unread,

Apr 11, 2021, 5:40:50 PM4/11/21

to

Juergen Ilse <ne...@usenet-verwaltung.de> writes:
> Rainer Weikusat <rwei...@talktalk.net> wrote:
>> Christian Hanné <the....@gmail.com> writes:
>>> Perl is out, Pyhton ist angesagt.
>>
>> Python ist was für Legastheniker :-)
>
> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
> wieder eingefuehrt ...

Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
semantisch relevant zu machen, ist bizarr. Zumal Python deswegen
keineswegs ohne Begrenzungszeichen auskommt: Nach einem Ausdruck in
einem Schleifen- oder Verzweigungsanweisung muß ein : stehen. Einziger
Zweck davon ist, daß man trotz der einrückungsbasierten Syntax 'kurze'
Schleifen oder Verzweigungen auf eine Zeile schreiben kann.

Da bin ich einige Male drüber gestolpert, als ich soviel Python lernen
mußte, um in nicht trivialem Code (bitbake) ein paar notwendige
Änderungen machen zu können.

Andererseits verstehe ich aber auch die Motivation dahinter: Viele Leute
benutzten zum Code-schreiben «Primitivwerkzeuge», die keine automatische
Einrückung können und sind außerdem auch viel zu faul, um über
konsistente Formatierung auch nur nachzudenken. Mit so geschriebenem Code
habe ich schon gearbeitet: Das gibt ein wildes Durcheinander
inkonsistent angewendeter persönlicher Formatierungsstile (wenn genügend
Leute daran arbeiten) und bevor man da durchblickt, ist es im
allgemeinen sinnvoll, alles erstmal automatisch konsistent formatieren
zu lassen. Da gibt es dann wiederum Leute, die viel zu ängstlich wären,
um an einem evtl großen Haufen unverständlichen Codes irgendwas zu
ändern. Wer kann schon sagen, das dann passieren wird!

Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
mal ein Problem. Bringt natürlich wenig, weil die Chaoten immer noch
chaotischen Code schreiben, aber wenigstens sieht er nett aus :-).

Gibt's übrigens noch einem besser: YAML (XML reloaded, sozuagen, da
weder les- noch parsebar). Dort werden sowohl Einrückungen als auch
geklammerte Blöcke für dieselben semantischen Konstrukte benutzt.

ZB:

vektor:
- 0
- 1
- 2
- 3

identisch zu (aus dem Kopf)

vektor: [0, 1,
2, 3
]

Natürlich gibt es Leute, die vollkommen überzeugt sind, beide
"Formationen" müßten unterschiedliches bedeuten, weil sie doch
unterschiedlich aussehen.

Marc 'BlackJack' Rintsch

unread,

Apr 28, 2021, 10:55:43 AM4/28/21

to

On Wed, 07 Apr 2021 18:10:19 +0200, Christian Hanné wrote:

> Perl is out, Pyhton ist angesagt.

```
#!/usr/bin/env python3
import random
import re

STEPS = [
["Was wir jetzt brauchen ist ein/e"],

["ein-", "zwei-", "drei-", "vier-", "fünf-", "sechs-"],

["tägige/r", "wöchige/r", "monatige/r", "fache/r", "malige/r", "hebige/r"],
[
"harte/r",
"softe/r",
"optionale/r",
"intransparente/r",
"alternativelose/r",
"unumkehrbare/r",
],
["Wellenbrecher-", "Brücken-", "Treppen-", "Wende-", "Impf-", "Ehren-"],
[
"Lockdown:m",
"Stopp:m",
"Maßnahme:w",
"Kampagne:w",
"Sprint:m",
"Matrix:w",

],
["bis"],
[
"zum Sommer",
"auf Weiteres",
"zur Bundestagswahl",
"2030",
"nach den Abiturprüfungen",
"in die Puppen",

],
["zur"],
[
"sofortigen",
"nachhaltigen",
"allmählichen",
"unausweichlichen",
"wirtschaftsschonenden",
"willkürlichen",
],
[
"Senkung",
"Steigerung",
"Beendigung",
"Halbierung",
"Vernichtung",
"Beschönigung",

],
["der"],
[
"Infektionszahlen",
"privaten Treffen",
"Wirtschaftsleistung",
"Wahlprognosen",
"dritten Welle",

"Bundesklanzlerin",
],
]

def concat(parts):
previous_part = ""
for part in parts:
if part.endswith("-"):
previous_part += part[:-1]
else:
if previous_part:
part = previous_part + part.lower()
yield part
previous_part = ""

def fixup_sex(parts):
result = []
indices_to_fix = []
for part in parts:
if re.search(r"\/[er]$", part):
indices_to_fix.append(len(result))
else:
match = re.fullmatch(r"(?P<part>.+):(?P<sex>[mw])", part)
if match:
part = match["part"]
keep = {"m": "r", "w": "e"}[match["sex"]]
for index in indices_to_fix:
part_to_fix = result[index]
result[index] = part_to_fix[:-2] + (
keep if part_to_fix.endswith(keep) else ""
)
indices_to_fix = []

result.append(part)

return result

def main():
print(" ".join(fixup_sex(concat(map(random.choice, STEPS)))), end=".\n")

if __name__ == "__main__":
main()
```

Ciao,
Marc 'BlackJack' Rintsch
--
“C is quirky, flawed, and an enormous success.“ -- Dennis M. Ritchie

Dietrich Clauss

unread,

Apr 28, 2021, 4:08:08 PM4/28/21

to

Rainer Weikusat wrote:
> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>> Christian Hanné <the....@gmail.com> writes:
>>>> Perl is out, Pyhton ist angesagt.
>>>
>>> Python ist was für Legastheniker :-)
>>
>> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
>> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
>> wieder eingefuehrt ...
>
> Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
> semantisch relevant zu machen, ist bizarr.

Was heißt hier 'unsichtbare Zeichen'? Eine Einrückung ist sehr wohl
sichtbar. Eine Einrückung bzw. deren Fehlen sticht sogar regelrecht ins
Auge, was man von einer (fehlenden) Klammer oder einem (fehlenden)
'begin' nicht behaupten kann.

> Zumal Python deswegen
> keineswegs ohne Begrenzungszeichen auskommt: Nach einem Ausdruck in
> einem Schleifen- oder Verzweigungsanweisung muß ein : stehen. Einziger
> Zweck davon ist, daß man trotz der einrückungsbasierten Syntax 'kurze'
> Schleifen oder Verzweigungen auf eine Zeile schreiben kann.
>
> Da bin ich einige Male drüber gestolpert, als ich soviel Python lernen
> mußte, um in nicht trivialem Code (bitbake) ein paar notwendige
> Änderungen machen zu können.
>
> Andererseits verstehe ich aber auch die Motivation dahinter: Viele Leute
> benutzten zum Code-schreiben «Primitivwerkzeuge», die keine automatische
> Einrückung können und sind außerdem auch viel zu faul, um über
> konsistente Formatierung auch nur nachzudenken. Mit so geschriebenem Code
> habe ich schon gearbeitet:

So geschriebener Code ist nicht die Motivation dahinter.

> Das gibt ein wildes Durcheinander
> inkonsistent angewendeter persönlicher Formatierungsstile (wenn genügend
> Leute daran arbeiten) und bevor man da durchblickt, ist es im
> allgemeinen sinnvoll, alles erstmal automatisch konsistent formatieren
> zu lassen. Da gibt es dann wiederum Leute, die viel zu ängstlich wären,
> um an einem evtl großen Haufen unverständlichen Codes irgendwas zu
> ändern. Wer kann schon sagen, das dann passieren wird!
>
> Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
> lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
> bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
> mal ein Problem.

Es /ist/ ein Geniestreich. Ja, den Doppelpunkt hätte man auch noch
einsparen können, und man hätte festlegen sollen, daß zum Einrücken
/genau/ /ein/ /Tab/ verwendet wird. Aber das kommt vielleicht noch.
Die Entwicklung der Sprache ist schließlich noch nicht zu Ende.

> Bringt natürlich wenig, weil die Chaoten immer noch
> chaotischen Code schreiben, aber wenigstens sieht er nett aus :-).

Chaotischer Code ist ein Totschlagargument, d.h. kein Argument. Der
Python-Ansatz bringt dort genauso wenig wie automatische
Formatierungstools bei anderen Sprachen.

Juergen Ilse

unread,

Apr 28, 2021, 6:59:24 PM4/28/21

to

Hallo,

Dietrich Clauss <diet...@clauss-it.com> wrote:
> Rainer Weikusat wrote:
>> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>>> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
>>> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
>>> wieder eingefuehrt ...
>>
>> Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
>> semantisch relevant zu machen, ist bizarr.
>
> Was heißt hier 'unsichtbare Zeichen'? Eine Einrückung ist sehr wohl
> sichtbar.

Aber *ein* <TAB> ist optisch nicht von einer entsprechenden Anzahl <BLANKS>
unterschiedbar, hat aber u.U. eine *voellig* *andere* Semantik. So etwas
auch nur fuer eine produktive programmiersprache anzudenken ist *PERVERS*-

> Eine Einrückung bzw. deren Fehlen sticht sogar regelrecht ins
> Auge, was man von einer (fehlenden) Klammer oder einem (fehlenden)
> 'begin' nicht behaupten kann.

Die fehlende Klammer oder das fehlende "begin" oder "end" wird i.d.R.
vom Compiler bemerkt und mit einer entsprechenden Fehlermeldung quittiert
(wenn die Zahl der "begin" und "end" oder die Zahl der oeffnenden und
schliessenden Klammern nicht mehr uebereinstimmt). Der Programmierer
wird sich also (wenn er eienen solchen Fehler eingebaut hat) nach dem
Fehler ssuchen muessen, der python Programmierer hat aber im Fall des
<TAB> kaum eine Chance ...

>> Andererseits verstehe ich aber auch die Motivation dahinter: Viele Leute
>> benutzten zum Code-schreiben «Primitivwerkzeuge», die keine automatische
>> Einrückung können und sind außerdem auch viel zu faul, um über
>> konsistente Formatierung auch nur nachzudenken. Mit so geschriebenem Code
>> habe ich schon gearbeitet:
>
> So geschriebener Code ist nicht die Motivation dahinter.

Das ist aber kein Argument, denn "echte Programmierer koennen in jeder
beliebigen Programmiersprache Fortran Programme schreiben" wie es so
schoen im Artikel "real programmers don't usee pascal" in der deutschen
Ueberseetzung heisst. Oder anders formuliert: Wer nicht an lesbarem Code
interessiert ist, wird auch in jeder noch so "zwanghaften Sprache"
unlesbaren Code schreiben koennen.

>> Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
>> lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
>> bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
>> mal ein Problem.

... nicht. Leider loest das das Problem keineswegs, es verschiebt es
bestenfalls ein bischen. Einigung ueber zu nutzende Programmier- und
Formatierungsrichtlinien im Team und konsequente Ablehnung von Code,
der nicht diesen Vorgaben entspricht (ggfs. mit entsprechenden dienst-
rechtlichen Konsequenzen) kann da hilfreich sein, und waere auch nicht
so einfach zu unterlaufen.

> Es /ist/ ein Geniestreich.

... mit sehr eigenartiger Auffassung von "Genie". In manchem Sinne ist
auch eine Programmiersprache wie "whitespace" ein "Geniestreich" ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

Thomas Koenig

unread,

Apr 29, 2021, 1:42:09 AM4/29/21

to

Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:

> Das ist aber kein Argument, denn "echte Programmierer koennen in jeder
> beliebigen Programmiersprache Fortran Programme schreiben" wie es so
> schoen im Artikel "real programmers don't usee pascal" in der deutschen
> Ueberseetzung heisst.

FORTRAN, bitte.

Fortran ist eine moderne Programmiersprache.

Dietrich Clauss

unread,

Apr 29, 2021, 5:08:08 AM4/29/21

to

Rainer Weikusat

unread,

Apr 29, 2021, 1:02:05 PM4/29/21

to

Dietrich Clauss <diet...@clauss-it.com> writes:
> Rainer Weikusat wrote:
>> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>>> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>>> Christian Hanné <the....@gmail.com> writes:
>>>>> Perl is out, Pyhton ist angesagt.
>>>>
>>>> Python ist was für Legastheniker :-)
>>>
>>> Bei anderen Sprachen hat es Jahrzehnte gekostet, um Syntax und Formatierung
>>> (sinnvollerweise) zu trennen. Bei Python hat man genau diesen Unsinn dann
>>> wieder eingefuehrt ...
>>
>> Grundsätzlich stimme ich dem zu: Der Gedanke, unsichtbare Zeichen
>> semantisch relevant zu machen, ist bizarr.
>
> Was heißt hier 'unsichtbare Zeichen'?

[rw@doppelsaurus]/tmp#cat a.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(int argc, char **argv)
{
unsigned x;

srand(time(NULL));
x = atoi(argv[1]);
do
putchar(rand() & 1 ? ' ' : '\t');
while (--x);

putchar('\n');

return 0;
}
[rw@doppelsaurus]/tmp#gcc a.c
[rw@doppelsaurus]/tmp#./a.out 50

[rw@doppelsaurus]/tmp#

Ermittle mit bloßem Auge, wieviele Zeichen in der Zeile vor dem letzten
Prompt stehen. :-)

Rainer Weikusat

unread,

Apr 29, 2021, 3:49:34 PM4/29/21

to

Juergen Ilse <ne...@usenet-verwaltung.de> writes:
> Rainer Weikusat wrote:

[...]

>> Diesem Chaos dadurch effektiv einen Riegel vorzuschieben, daß man eine
>> lesbare Formatierung als Seiteneffekt syntaktischer Notwendigkeiten
>> bekommt, kann einem wie ein Geniestreich vorkommen. Jedenfalls löst es
>> mal ein Problem.
>
> ... nicht. Leider loest das das Problem keineswegs, es verschiebt es
> bestenfalls ein bischen. Einigung ueber zu nutzende Programmier- und
> Formatierungsrichtlinien im Team und konsequente Ablehnung von Code,
> der nicht diesen Vorgaben entspricht (ggfs. mit entsprechenden dienst-
> rechtlichen Konsequenzen) kann da hilfreich sein, und waere auch nicht
> so einfach zu unterlaufen.

Entwicklung wird nicht nur von Konzernen und öffentlichen Einrichtungen
betrieben und in vielen Fällen kann man bei neuen Kollegen schon froh
sein, wenn sie überhaupt Code schreiben können, der wenigstens ungefähr
das tut, was er tun müßte. :-)

Rainer Weikusat

unread,

Apr 29, 2021, 3:55:16 PM4/29/21

to

Marcus Jodorf <tr...@killfile.de> writes:
> Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:

>> Die fehlende Klammer oder das fehlende "begin" oder "end" wird i.d.R.
>> vom Compiler bemerkt und mit einer entsprechenden Fehlermeldung
>> quittiert (wenn die Zahl der "begin" und "end" oder die Zahl der
>> oeffnenden und schliessenden Klammern nicht mehr uebereinstimmt). Der
>> Programmierer wird sich also (wenn er eienen solchen Fehler eingebaut
>> hat) nach dem Fehler ssuchen muessen, der python Programmierer hat
>> aber im Fall des <TAB> kaum eine Chance ...
>

> Du meinst kaum eine Chance, weil die Fehlermeldung
>
> File „blah“, line xxx
> TabError: inconsistent use of tabs and spaces in indention
>
> bei der Interpretersprache viel zu unmittelbar kommt, während sich beim
> Compiler der Programmierer wenigstens schon mal noch mental drauf
> einstellen kann, während der Compiler erst mal noch rödelt?
>
> Ernsthaft: Das ist Quatsch. Fehlermeldungen haben sie bei python nicht
> abgeschafft und je nach Situation sind die da genauso mal mehr oder
> weniger hilfreich wie bei jeder anderen Sprache auch.
> Du beschreibst da ein Problem, das so nicht wirklich existiert.

Dafür existiert ein anderes Problem: Pythoncode ist
positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
damit die Semantik wieder stimmt.

Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
verschobener Block fügt sich ganz von Selbst in seinen neuern,
übergeordneten Block ein und man kann ihn automatisch «richtig»
formatieren lassen.

Dietrich Clauss

unread,

Apr 30, 2021, 5:08:08 AM4/30/21

to

Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
Python eben auch horizontal. Problem gelöst.

Dietrich Clauss

unread,

Apr 30, 2021, 5:08:08 AM4/30/21

to

Sehr witzig. Wenn jemand eine Syntax erfinden würde, in der /trailing
whitespace/ eine Bedeutung hat[1], wäre das Geschrei ja in gewisser
Weise nachvollziehbar. Das ist bei Python aber gerade nicht der Fall.

- Dietrich

[1] Ja, sowas gibts. Bei LDIF kann man Zeilenumbrüche quoten, indem man
die Folgezeile um genau ein Leerzeichen einrückt. Whitespace am Ende
der aktuellen Zeile geht dann mit ins Ergebnis ein. Dort habe ich mich
auch gefragt, was da geraucht wurde und wie man auf die Idee kommt,
sowas als menschenles- und v.a. schreibbar zu bezeichnen.

Rainer Weikusat

unread,

Apr 30, 2021, 9:16:49 AM4/30/21

to

Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
manuell um diese Sprachdesignproblem herumwürgen.

Rainer Weikusat

unread,

Apr 30, 2021, 9:21:34 AM4/30/21

to

Wir halten also mal fest, daß ASCII-codes (in diesem Fall), denen keine
Grapheme zugeordnet sind, tatsächlich «unsichtbar» sind (warum auch
immer jemand meinte, daß bestreiten zu müssen). Darum ging es in meiner
Aussage.

Übrigens werden Text nicht dadurch aussagekräftiger, daß man unmotiviert
emotional stark aufgeladene und vollkommen unpassende Begriffe darin
unterbringt (wie «Geschrei»). Das läßt bestenfalls auf einen
Mangel an kommunikativen Fähgkeiten schließen.

Оlе Ѕtrеісhеr

unread,

Apr 30, 2021, 9:42:48 AM4/30/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>> positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
>>> Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
>>> wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
>>> eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
>>> damit die Semantik wieder stimmt.
>>>
>>> Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
>>> verschobener Block fügt sich ganz von Selbst in seinen neuern,
>>> übergeordneten Block ein und man kann ihn automatisch «richtig»
>>> formatieren lassen.
>>
>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>> Python eben auch horizontal. Problem gelöst.
>
> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
> manuell um diese Sprachdesignproblem herumwürgen.

Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
das Reformat wird der Code schnell unlesbar.

Und das ist ein generelles Problem mit C, Java & Co: es gibt keinerlei
Vorschriften, wie eine bestimmte Programmstruktur visuell dargestellt
wird -- bzw. es gibt genügend davon, sodas sich jeder seine ganz eigene
aussuchen kann. Dagegen hat Python einen Großteil der Formatierung schon
in die Sprache selbst gesteckt, und einen weiteren Teil in PEP-8. Das
sorgt für eine standardisierte Darstellung des Codes, die bei der
Einarbeitung in fremden (professionellen) Code sehr hilfreich ist.

Dagegen kocht in C jeder sein eigenes Süppchen. Wenn an in mehr als
einem Projekt arbeitet, muss man daher jedesmal neu überlegen, wie eine
gewisse Programmstruktur visuell dargestellt wird. Einer schnellen
Einarbeitung ist das eher nicht zuträglich.

Meines Erachtens hat das was mit dem Selbstverständnis der Entwickler
zum Zeitpunkt der Sprachentwicklung zu tun: in den 70/80ern (C) sahen
sie sich als hochkreative Leute, denen möglichst wenig Schranken
auferlegt werden sollten. Und solange Software auch von Einzelpersonen
bzw. kleinen festen Teams entwickelt wurde, war das ja auch OK.

Heute hat man es dagegen mit Entwicklungen zu tun, die von vielen
Einzelpersonen getragen werden -- hunderte Entwickler sind bei großen
Projekten nicht unüblich. Von denen tragen aber viele nur einige Zeilen
Code bei. Damit das klappt, müssen sich diese Leute schnell in den Code
einarbeiten können, und da hilft eine weitgehend eindeutige Formatierung
ungemein; selbst dann wenn sie nicht perfekt den eigenen Vorstellungen
entspricht.

Ole

Rainer Weikusat

unread,

Apr 30, 2021, 10:27:52 AM4/30/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>>> positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
>>>> Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
>>>> wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
>>>> eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
>>>> damit die Semantik wieder stimmt.
>>>>
>>>> Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
>>>> verschobener Block fügt sich ganz von Selbst in seinen neuern,
>>>> übergeordneten Block ein und man kann ihn automatisch «richtig»
>>>> formatieren lassen.
>>>
>>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>>> Python eben auch horizontal. Problem gelöst.
>>
>> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
>> manuell um diese Sprachdesignproblem herumwürgen.
>
> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
> das Reformat wird der Code schnell unlesbar.

In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
das automatisch erledigen. Das ist mit Python grundsätzlich nicht
möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
verursacht).

Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.

> Und das ist ein generelles Problem mit C, Java & Co: es gibt keinerlei
> Vorschriften, wie eine bestimmte Programmstruktur visuell dargestellt
> wird -- bzw. es gibt genügend davon, sodas sich jeder seine ganz eigene
> aussuchen kann. Dagegen hat Python einen Großteil der Formatierung schon
> in die Sprache selbst gesteckt, und einen weiteren Teil in PEP-8. Das
> sorgt für eine standardisierte Darstellung des Codes, die bei der
> Einarbeitung in fremden (professionellen) Code sehr hilfreich ist.

Entgegen von Lieblingsannahmem der Whitespace-Sammler ist die
Formatierung von Code zur Einarbeitung in ihn vollkommen unerheblich
(außer in Python, natürlich, wo sie eine zusätzliche Komplikation
darstellt) oder - um genauer zu sagen - wenn der Code so trivial ist,
daß sein Inhalt sich ohne eine gründliche Analyse erschließt, dann ist
die Formatierung auch vollkommen egal.

[rw@doppelsaurus]~#perl <<TT
print 1
TT
[rw@doppelsaurus]~#
[rw@doppelsaurus]~#perl <<TT
print 1
TT
1[rw@doppelsaurus]~#perl <<TT
[rw@doppelsaurus]~#perl <<TT
> print
>
>
>
> 1
> TT
1[rw@doppelsaurus]~#

wird beides niemandem Rätsel aufgeben.

Оlе Ѕtrеісhеr

unread,

Apr 30, 2021, 10:50:10 AM4/30/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
> Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>>>> positionsabhängig. Im Prinzip ist jede Codefolge eine manuelle
>>>>> Einzelanfertigung, die genau an die Programmstelle paßt, wo sie angefügt
>>>>> wurde. Verschiebt man einen inhaltliche zusammenhängende Codeblock an
>>>>> eine ander Stelle, muß man die Formatierung manuell richtig anpassen,
>>>>> damit die Semantik wieder stimmt.
>>>>>
>>>>> Für Sprachen mit expliziten Blockbegrenzern ist das nicht notwendig: Ein
>>>>> verschobener Block fügt sich ganz von Selbst in seinen neuern,
>>>>> übergeordneten Block ein und man kann ihn automatisch «richtig»
>>>>> formatieren lassen.
>>>>
>>>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>>>> Python eben auch horizontal. Problem gelöst.
>>>
>>> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
>>> manuell um diese Sprachdesignproblem herumwürgen.
>>
>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>> das Reformat wird der Code schnell unlesbar.
>
> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
> verursacht).

Das gibt es auch in Python. Es ist ja wirklich nur die richtige
Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
mit M-q für den passenden Zeilenumbruch. Über den dazu nötigen
Zeitaufwand zu reden ist ein wenig müßig, zumal man ja sofort *sieht*,
ob der Codeblock korrekt eingerückt ist.

> Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
> semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
> grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.

Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
die Einbindung in die Umgebung hängt von der Einrückung ab.

Sicher lassen sich da Ausnahmen finden, aber die bastele ich Dir im
Notfall auch für C zusammen.

>> Und das ist ein generelles Problem mit C, Java & Co: es gibt keinerlei
>> Vorschriften, wie eine bestimmte Programmstruktur visuell dargestellt
>> wird -- bzw. es gibt genügend davon, sodas sich jeder seine ganz eigene
>> aussuchen kann. Dagegen hat Python einen Großteil der Formatierung schon
>> in die Sprache selbst gesteckt, und einen weiteren Teil in PEP-8. Das
>> sorgt für eine standardisierte Darstellung des Codes, die bei der
>> Einarbeitung in fremden (professionellen) Code sehr hilfreich ist.
>
> Entgegen von Lieblingsannahmem der Whitespace-Sammler ist die
> Formatierung von Code zur Einarbeitung in ihn vollkommen unerheblich
> (außer in Python, natürlich, wo sie eine zusätzliche Komplikation
> darstellt) oder - um genauer zu sagen - wenn der Code so trivial ist,
> daß sein Inhalt sich ohne eine gründliche Analyse erschließt, dann ist
> die Formatierung auch vollkommen egal.

Ich kann hier nur aus Erfahrung mit der Maintainance von diversen
Debian-Paketen reden, die sowohl Python als auch C, C++, Java, Fortran
und einiges andere umfassen. Und ich bin lange genug dabei, keine Angst
vor irgendeiner Sprache zu haben (sagen wir mal: außer Perl). Trotzdem
sind mir die Pythonprojekte am liebsten; einfach weil ich dort innerhalb
von Minuten klarkomme und Fixes propagieren kann, wenn ich einen Fehler
finde.

Das liegt sicher nicht nur an der starken visuellen Standardisierung von
Pythoncode, aber das ist (subjektiv) einer der Gründe.

Ole

Stefan Reuther

unread,

Apr 30, 2021, 11:23:42 AM4/30/21

to

Am 30.04.2021 um 16:50 schrieb Ole Streicher:
> Rainer Weikusat <rwei...@talktalk.net> writes:

>> Ole Streicher <ole-use...@gmx.net> writes:
>>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>>> das Reformat wird der Code schnell unlesbar.
>>
>> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
>> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
>> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
>> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
>> verursacht).
>
> Das gibt es auch in Python. Es ist ja wirklich nur die richtige
> Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
> mit M-q für den passenden Zeilenumbruch.

Für C, C++, Perl, Shell, Pascal, JavaScript reicht einmal Tab.

Bei Python ist der Code nach dem Tab meistens kaputt.

Das ist halt einfach Redundanz. Die hilft ansonsten auch z.B. Code durch
kaputte Mailer zu bringen (war Google nicht mal so ein
Whitespace-Fresser?). Und: wenn der Code nach Tab falsch aussieht, fehlt
irgendwo ein Semikolon oder eine Klammer.

> Trotzdem sind mir die Pythonprojekte am liebsten; einfach weil ich
> dort innerhalb von Minuten klarkomme und Fixes propagieren kann, wenn
> ich einen Fehler finde.
>
> Das liegt sicher nicht nur an der starken visuellen Standardisierung von
> Pythoncode, aber das ist (subjektiv) einer der Gründe.

Die meisten anderen Sprachen sind auch visuell halbwegs standardisiert.
Klar, es gibt 1TBS vs. Allman vs. GNU, aber wenn's um's lesen geht,
macht das keinen Unterschied.

Da ist eher relevant, ob meine müden Augen mit 2er Einrückung gefordert
werden oder entspannte 4 oder 8 vorgesetzt bekommen. *Das* Problem hat
Python aber auch. Sogar noch mehr, weil ein "springe zur passenden
schließenden Klammer" (M-C-f / M-C-b) fehlt.

Aber am Ende würde es nicht mehrere Sprachen geben, wenn es nicht
mehrere Geschmäcker gäbe. Objektorientierung macht in Python irgendwie
mehr Spaß als in Perl.

Stefan

Оlе Ѕtrеісhеr

unread,

Apr 30, 2021, 11:51:28 AM4/30/21

to

Stefan Reuther <stefa...@arcor.de> writes:
> Am 30.04.2021 um 16:50 schrieb Ole Streicher:
>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>> Ole Streicher <ole-use...@gmx.net> writes:
>>>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>>>> das Reformat wird der Code schnell unlesbar.
>>>
>>> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
>>> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
>>> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
>>> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
>>> verursacht).
>>
>> Das gibt es auch in Python. Es ist ja wirklich nur die richtige
>> Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
>> mit M-q für den passenden Zeilenumbruch.
>
> Für C, C++, Perl, Shell, Pascal, JavaScript reicht einmal Tab.

Aber nur, wenn der Editor entsprechend den Regeln der entsprechenden
Entwicklergemeinde eingerichtet ist. Und da unterscheidet sich mein
Editor von den meisten Regeln der von mir betreuten Pakete an der einen
oder anderen Stelle.

> Bei Python ist der Code nach dem Tab meistens kaputt.

Das passiert mir eigentlich nie.

> Das ist halt einfach Redundanz. Die hilft ansonsten auch z.B. Code durch
> kaputte Mailer zu bringen (war Google nicht mal so ein
> Whitespace-Fresser?).

Mailtexte sind als Codeverteiler generell nicht wirklich geeignet. Und
in Anhängen passiert das eher selten. Ich bin mir auch nicht sicher, ob
man eine Programmiersprache nach Bugs in einigen Mailprogrammen
ausrichten sollte.

> Und: wenn der Code nach Tab falsch aussieht, fehlt irgendwo ein
> Semikolon oder eine Klammer.

Wenn der Code visuell nicht die von mir intendierte Struktur
widerspiegelt, dann ist da irgendwas falsch. Auch ohne Semikolons oder
Klammern.

>> Trotzdem sind mir die Pythonprojekte am liebsten; einfach weil ich
>> dort innerhalb von Minuten klarkomme und Fixes propagieren kann, wenn
>> ich einen Fehler finde.
>>
>> Das liegt sicher nicht nur an der starken visuellen Standardisierung von
>> Pythoncode, aber das ist (subjektiv) einer der Gründe.
>
> Die meisten anderen Sprachen sind auch visuell halbwegs standardisiert.
> Klar, es gibt 1TBS vs. Allman vs. GNU, aber wenn's um's lesen geht,
> macht das keinen Unterschied.

Meine Erfahrung: es macht einen Unterschied. Gerade wenn man schnell
einen Überblick bekommen möchte, ist eine hochstandardisierte
Formatierung sehr hilfreich.

> Da ist eher relevant, ob meine müden Augen mit 2er Einrückung gefordert
> werden oder entspannte 4 oder 8 vorgesetzt bekommen. *Das* Problem hat
> Python aber auch.

Nicht mit PEP-8.

> Sogar noch mehr, weil ein "springe zur passenden schließenden Klammer"
> (M-C-f / M-C-b) fehlt.

Das hätte ich manchmal auch gerne; es stellt aber eher ein
Implementations- als ein prinzipielles Problem dar. Emacs müsste ja
einfach an die letzte Codezeile mit mindestens der passenden Einrückung
springen.

> Aber am Ende würde es nicht mehrere Sprachen geben, wenn es nicht
> mehrere Geschmäcker gäbe. Objektorientierung macht in Python irgendwie
> mehr Spaß als in Perl.

Nun hängen Programmiersprachen eben heutzutage nicht mehr so stark vom
persönlichen "Geschmack" ab, sondern von kollektiven Entscheidungen.

Ole

Bonita Montero

unread,

Apr 30, 2021, 12:10:52 PM4/30/21

to

> Aber *ein* <TAB> ist optisch nicht von einer entsprechenden Anzahl <BLANKS>
> unterschiedbar, hat aber u.U. eine *voellig* *andere* Semantik. So etwas
> auch nur fuer eine produktive programmiersprache anzudenken ist *PERVERS*-

So kann das nur ein Mensch mit gestörtem Sicherheitsgefühl sehen,
und so einer bist Du. Wenn man aber eine richtige IDE nimmt, die
IDEs für Python werden sicher Tabs sein lassen, dann ist das kein
Problem.

Bonita Montero

unread,

Apr 30, 2021, 12:12:41 PM4/30/21

to

>> Man schiebt den Codeblock an die gewünschte Position, vertikal, und bei
>> Python eben auch horizontal. Problem gelöst.

> Das ist eine Wiederholung eines Teils meines Textes. Natürlich kann man
> manuell um diese Sprachdesignproblem herumwürgen.

Das ist kein Problem und das ist kein Herumwürgen.

Rainer Weikusat

unread,

Apr 30, 2021, 1:46:58 PM4/30/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>> Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
>>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>>>>> Dafür existiert ein anderes Problem: Pythoncode ist
>>>>>> positionsabhängig.

[...]

>>> Naja, fast: in C "muss" man natürlich nicht neu formatieren, aber ohne
>>> das Reformat wird der Code schnell unlesbar.
>>
>> In C muß man vor allem nie «neu formatieren», denn es gibt Werkzeuge, die
>> das automatisch erledigen. Das ist mit Python grundsätzlich nicht
>> möglich. Das ist aber mehr ein Nebenaspekt (obwohl es natürlich beim
>> Arbeiten mit existierenden Code vollkommen vermeidbare Mehrarbeit
>> verursacht).
>
> Das gibt es auch in Python. Es ist ja wirklich nur die richtige
> Einrückung, und das macht mein Emacs mit C-c > bzw. C-c < . Eventuell
> mit M-q für den passenden Zeilenumbruch. Über den dazu nötigen
> Zeitaufwand zu reden ist ein wenig müßig, zumal man ja sofort *sieht*,
> ob der Codeblock korrekt eingerückt ist.

Sicher kann das beim schreiben heuristisch einrücken. Ich hatte aber von
etwas anderem geschrieben, nämlich einen existierenden Codeblock, der an
eine andere Textstelle verschoben (oder kopiert) wurde, automatisch so
umzuformatieren, daß er optisch an seine neue Position paßt.

Ist aber wirklich ein relativ uninteressanter Nebenaspekt.

>> Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
>> semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
>> grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.
>
> Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
> die Einbindung in die Umgebung hängt von der Einrückung ab.

Die Einrück ist semantisch relevanter Bestandteil des Quelltexts und
hängt in der beschriebenen Art und Weise von allen übergeordneten
Blöcken ab. Kann man als rekursive Funktion definieren: Sei n die
Blocktiefe und f(n) eine Funktion, deren Wert die minimal notwendige
Einrückung eines Blocks an Tiefe n ist, dann gilt

f(0) = 0
f(n) = 1 + f(n - 1)

Rainer Weikusat

unread,

Apr 30, 2021, 2:29:15 PM4/30/21

to

Stefan Reuther <stefa...@arcor.de> writes:
> Am 30.04.2021 um 16:50 schrieb Ole Streicher:

[...]

> Aber am Ende würde es nicht mehrere Sprachen geben, wenn es nicht
> mehrere Geschmäcker gäbe. Objektorientierung macht in Python irgendwie
> mehr Spaß als in Perl.

Ich betreibe OO-Programmierung in Perl seit ungefähr 25 Jahren und finde
das immer noch eine sehr angenehme Umgebung zum Lösen von Problemen, an
der ich auch immer noch etwas neues, nützliches entdecke[*]. Und damit
meine ich Perl und nicht «die Sprache, die von CPAN-Autoren zufällig
benutzt wird» (obwohl sie sie größtenteils nicht mögen).

[*] Neuestes Beispiel: Dinge wie "epoll event handler" (oder "time event
handler") kann man als Instanzen von Klassen reprästentieren, deren
Destruktor den entsprechenden Abbau implementiert. Finde ich echt
praktisch. Solange mich ein Ereignis interessiert, habe ich das
handler-Objekt auf. Wenn es mich nicht mehr interessiert, kehre ich es
vom Tisch und es räumt sich selber auf.

Оlе Ѕtrеісhеr

unread,

Apr 30, 2021, 2:40:33 PM4/30/21

to

... der, wenn es denn wirklich relevant wäre, schon in den üblichen
Codeeditoren implementiert wäre. Es ist ja nicht so, dass das (abgesehem
von Spezialfällen, wie dem Ende eines Blocks) nicht weitgehend
automatisierbar wäre.

>>> Das Problem ist, daß der Inhalt eines zusammenhängende Quellcodeblocks
>>> semantisch von allen äußeren Quellcodeblöcken abhängig ist. Damit ist er
>>> grundsätzlich kein «strukturiertes» Programmkonstrukt mehr.
>>
>> Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
>> die Einbindung in die Umgebung hängt von der Einrückung ab.
>
> Die Einrück ist semantisch relevanter Bestandteil des Quelltexts und
> hängt in der beschriebenen Art und Weise von allen übergeordneten
> Blöcken ab. Kann man als rekursive Funktion definieren: Sei n die
> Blocktiefe und f(n) eine Funktion, deren Wert die minimal notwendige
> Einrückung eines Blocks an Tiefe n ist, dann gilt
>
> f(0) = 0
> f(n) = 1 + f(n - 1)

Man kann Dinge natürlich auch versuchen, theoretisch zu
verschwurbeln. Ich würde die gemeinsame Einrückung eines Codeblocks
nicht als Bestandteil des Blockes selber ansehen.

Ich wüsste nur nicht, warum das von Belang ist.

Ole

Rainer Weikusat

unread,

Apr 30, 2021, 3:30:24 PM4/30/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:

[...]

>>> Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
>>> die Einbindung in die Umgebung hängt von der Einrückung ab.
>>
>> Die Einrück ist semantisch relevanter Bestandteil des Quelltexts und
>> hängt in der beschriebenen Art und Weise von allen übergeordneten
>> Blöcken ab. Kann man als rekursive Funktion definieren: Sei n die
>> Blocktiefe und f(n) eine Funktion, deren Wert die minimal notwendige
>> Einrückung eines Blocks an Tiefe n ist, dann gilt
>>
>> f(0) = 0
>> f(n) = 1 + f(n - 1)
>
> Man kann Dinge natürlich auch versuchen, theoretisch zu
> verschwurbeln. Ich würde die gemeinsame Einrückung eines Codeblocks
> nicht als Bestandteil des Blockes selber ansehen.

Für Python ist diese Ansicht falsch: Einrückung markiert die
Blockstruktur des Code, somit ist sie Bestandteil jedes Blocks. Weil sie
außerdem von der Einrückung der übergeordneten Blöcke abhängt, ist der
Block als solcher kein von seiner Umgebung unabhängiges Konstrukt (wie
in anderen Sprachen, die ein Konzept «Block» unterstützen). Unter
anderem heißt das, daß er nicht «beweglich» ist: Wird er verschoben, muß
er geändert werden und zwar nicht mechanisch sondern hier muß ein Mensch
die «richtigen» Entscheidungen treffen und den Text entsprechend
umarbeiten.

Оlе Ѕtrеісhеr

unread,

Apr 30, 2021, 5:22:07 PM4/30/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
> Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
>> Rainer Weikusat <rwei...@talktalk.net> writes:
>
> [...]
>
>>>> Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
>>>> die Einbindung in die Umgebung hängt von der Einrückung ab.
>>>
>>> Die Einrück ist semantisch relevanter Bestandteil des Quelltexts und
>>> hängt in der beschriebenen Art und Weise von allen übergeordneten
>>> Blöcken ab. Kann man als rekursive Funktion definieren: Sei n die
>>> Blocktiefe und f(n) eine Funktion, deren Wert die minimal notwendige
>>> Einrückung eines Blocks an Tiefe n ist, dann gilt
>>>
>>> f(0) = 0
>>> f(n) = 1 + f(n - 1)
>>
>> Man kann Dinge natürlich auch versuchen, theoretisch zu
>> verschwurbeln. Ich würde die gemeinsame Einrückung eines Codeblocks
>> nicht als Bestandteil des Blockes selber ansehen.
>
> Für Python ist diese Ansicht falsch: Einrückung markiert die
> Blockstruktur des Code, somit ist sie Bestandteil jedes Blocks.

An dieser Stelle fängt man an, Krümel zu kacken. Die gemeinsame
Einrückung eines Blocks markiert die Stellung, die dieser Block in
seinem Kontext hat, und die Einrückungen innerhalb des Blockes markieren
die Struktur des Blockes selbst.

> Weil sie außerdem von der Einrückung der übergeordneten Blöcke
> abhängt, ist der Block als solcher kein von seiner Umgebung
> unabhängiges Konstrukt (wie in anderen Sprachen, die ein Konzept
> «Block» unterstützen). Unter anderem heißt das, daß er nicht
> «beweglich» ist: Wird er verschoben, muß er geändert werden und zwar
> nicht mechanisch sondern hier muß ein Mensch die «richtigen»
> Entscheidungen treffen und den Text entsprechend umarbeiten.

Wenn *inhaltlich* klar ist, wo ein Block hinkommt, dann kann der Rest in
jeder Sprache automatisch erfolgen. Einen Editor hindert nichts daran,
einen ausgeschnittenen Block je nach Zielcursorspalte (falls relevant)
automatisch einzurücken und ggfs. neu zu formatieren.

Ole

Rainer Weikusat

unread,

Apr 30, 2021, 6:09:21 PM4/30/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>> Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
>>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>
>> [...]
>>
>>>>> Der Inhalt eines "Blocks" ist in Python auch unabhängig vom Rest. Nur
>>>>> die Einbindung in die Umgebung hängt von der Einrückung ab.
>>>>
>>>> Die Einrück ist semantisch relevanter Bestandteil des Quelltexts und
>>>> hängt in der beschriebenen Art und Weise von allen übergeordneten
>>>> Blöcken ab. Kann man als rekursive Funktion definieren: Sei n die
>>>> Blocktiefe und f(n) eine Funktion, deren Wert die minimal notwendige
>>>> Einrückung eines Blocks an Tiefe n ist, dann gilt
>>>>
>>>> f(0) = 0
>>>> f(n) = 1 + f(n - 1)
>>>
>>> Man kann Dinge natürlich auch versuchen, theoretisch zu
>>> verschwurbeln. Ich würde die gemeinsame Einrückung eines Codeblocks
>>> nicht als Bestandteil des Blockes selber ansehen.
>>
>> Für Python ist diese Ansicht falsch: Einrückung markiert die
>> Blockstruktur des Code, somit ist sie Bestandteil jedes Blocks.
>
> An dieser Stelle fängt man an, Krümel zu kacken. Die gemeinsame
> Einrückung eines Blocks markiert die Stellung, die dieser Block in
> seinem Kontext hat, und die Einrückungen innerhalb des Blockes markieren
> die Struktur des Blockes selbst.

Es gibt keine Einrückungen innerhalb eines Blocks: Das wären dann
untergeordnete bzw enthaltene Blöcke. Ansonsten äußere ich mich hier zu
etwas, das Python wesentlich von andern, blockstrukturierten Sprachen
unterscheidet, nämlich die Tatsache, daß Python nicht wirklich
blockstrukturiert ist, weil es «Block» als in sich abgeschlossenes, von
seinem Kontext grundsätzlich unabhängiges Konstrukt (Definition von Hoare
in Structured Programming) in Python nicht gibt.

>> Weil sie außerdem von der Einrückung der übergeordneten Blöcke
>> abhängt, ist der Block als solcher kein von seiner Umgebung
>> unabhängiges Konstrukt (wie in anderen Sprachen, die ein Konzept
>> «Block» unterstützen). Unter anderem heißt das, daß er nicht
>> «beweglich» ist: Wird er verschoben, muß er geändert werden und zwar
>> nicht mechanisch sondern hier muß ein Mensch die «richtigen»
>> Entscheidungen treffen und den Text entsprechend umarbeiten.
>
> Wenn *inhaltlich* klar ist, wo ein Block hinkommt, dann kann der Rest in
> jeder Sprache automatisch erfolgen.

Dadurch, daß irgendjemandem etwas «klar» ist (oder auch nicht) «erfolgt»
gar nichts: Am Zielort des Code gibt es eine hierarchische Folge von n
Blöcken. Der kopierte Code soll entweder an einen von diesen angefügt
werden oder ein Unterblock auf Ebene n + 1 werden. Darüber hat der
Computer keinerlei Information, denn explizite Blockbegrenzungen, anhand
derer daß festgestellt werden könnte, gibt es nicht. Also muß derjenige,
der den Block verschoben hat, ermitteln, was die korrekte Einrückung für
die Ziel-Hierarchieebene ist und die Formatierung entsprechend ändern
(ggf computerunterstützt).

Оlе Ѕtrеісhеr

unread,

May 1, 2021, 4:00:06 AM5/1/21

to

Eben: ein Block kann auch weitere, Blöcke enthalten.

> Ansonsten äußere ich mich hier zu etwas, das Python wesentlich von
> andern, blockstrukturierten Sprachen unterscheidet, nämlich die
> Tatsache, daß Python nicht wirklich blockstrukturiert ist, weil es
> «Block» als in sich abgeschlossenes, von seinem Kontext grundsätzlich
> unabhängiges Konstrukt (Definition von Hoare in Structured
> Programming) in Python nicht gibt.

Natürlich gibt es das. Es sind alle Codezeilen, die zusammenhängend
mindestens soweit wie die erste Zeile eingerückt sind.

Das ist auch äquivalent: Man kann (näherungsweise) den Doppelpunkt +
folgende Einrückung durch "{" ersetzen, und die entsprechende Ausrückung
durch "}", dann hat man den Block auch durch entsprechende Zeichen
markiert. Diese Operation ist reversibel, also sind beide Darstellungen
äquivalent.

>>> Weil sie außerdem von der Einrückung der übergeordneten Blöcke
>>> abhängt, ist der Block als solcher kein von seiner Umgebung
>>> unabhängiges Konstrukt (wie in anderen Sprachen, die ein Konzept
>>> «Block» unterstützen). Unter anderem heißt das, daß er nicht
>>> «beweglich» ist: Wird er verschoben, muß er geändert werden und zwar
>>> nicht mechanisch sondern hier muß ein Mensch die «richtigen»
>>> Entscheidungen treffen und den Text entsprechend umarbeiten.
>>
>> Wenn *inhaltlich* klar ist, wo ein Block hinkommt, dann kann der Rest in
>> jeder Sprache automatisch erfolgen.
>
> Dadurch, daß irgendjemandem etwas «klar» ist (oder auch nicht) «erfolgt»
> gar nichts: Am Zielort des Code gibt es eine hierarchische Folge von n
> Blöcken. Der kopierte Code soll entweder an einen von diesen angefügt
> werden oder ein Unterblock auf Ebene n + 1 werden. Darüber hat der
> Computer keinerlei Information, denn explizite Blockbegrenzungen, anhand
> derer daß festgestellt werden könnte, gibt es nicht.

Die Einrückung ist explizit, deren Änderung ebenfalls. Sie ist lediglich
kein eigenständiges Symbol.

> Also muß derjenige, der den Block verschoben hat, ermitteln, was die
> korrekte Einrückung für die Ziel-Hierarchieebene ist und die
> Formatierung entsprechend ändern (ggf computerunterstützt).

Ansonsten muss man das zur Hierarchieebene gehörende Ende-Symbol finden
und die Formatierung ändern (ggf computerunterstützt). Das ist äquivalent.

Ole

Dietrich Clauss

unread,

May 1, 2021, 7:08:08 AM5/1/21

to

Оlе Ѕtrеісhеr wrote:
> Ich würde die gemeinsame Einrückung eines Codeblocks
> nicht als Bestandteil des Blockes selber ansehen.

Ich auch nicht, und das ist vmtl. der Knackpunkt. Vielleicht kann man
es so ausdrücken: In Python hat ein Block eine rechteckige Form. Der
Whitespace links davon gehört zum den Block umgebenden Code. Hat man
das verinnerlicht, so kann man in Python die Codeblöcke genauso
umherschieben wie in anderen Sprachen auch.

Rainer Weikusat

unread,

May 2, 2021, 3:02:18 PM5/2/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:

[...]

>> Ansonsten äußere ich mich hier zu etwas, das Python wesentlich von
>> andern, blockstrukturierten Sprachen unterscheidet, nämlich die
>> Tatsache, daß Python nicht wirklich blockstrukturiert ist, weil es
>> «Block» als in sich abgeschlossenes, von seinem Kontext grundsätzlich
>> unabhängiges Konstrukt (Definition von Hoare in Structured
>> Programming) in Python nicht gibt.
>
> Natürlich gibt es das. Es sind alle Codezeilen, die zusammenhängend
> mindestens soweit wie die erste Zeile eingerückt sind.

Weil die Einrückung allerdings von Kontext abhängig ist, ist «der Block»
das ebenfalls. Allerdings sehe ich keinen Sinn darin, hier forwährend
Selbverständlichkeiten in einer Diskussion, die sich halb ausschließlich
darauf beschänkt, Fakten zu bestreiten zu wiederholen.

Sieghard Schicktanz

unread,

May 3, 2021, 4:13:06 PM5/3/21

to

Hallo Rainer,

Du schriebst am Sun, 02 May 2021 20:02:15 +0100:

[Python]

> Weil die Einrückung allerdings von Kontext abhängig ist, ist «der Block»
> das ebenfalls. Allerdings sehe ich keinen Sinn darin, hier forwährend
> Selbverständlichkeiten in einer Diskussion, die sich halb ausschließlich
> darauf beschänkt, Fakten zu bestreiten zu wiederholen.

Gib's zu: Du hast nur keinen Editor, der in der Lage ist, Textblocks
formatrichtig an eine andere Stelle zu versetzen oder einzufügen.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

Rainer Weikusat

unread,

May 3, 2021, 4:22:09 PM5/3/21

to

Sieghard Schicktanz <Sieghard....@SchS.de> writes:
> Hallo Rainer,
>
> Du schriebst am Sun, 02 May 2021 20:02:15 +0100:
>
> [Python]
>> Weil die Einrückung allerdings von Kontext abhängig ist, ist «der Block»
>> das ebenfalls. Allerdings sehe ich keinen Sinn darin, hier forwährend
>> Selbverständlichkeiten in einer Diskussion, die sich halb ausschließlich
>> darauf beschänkt, Fakten zu bestreiten zu wiederholen.
>
> Gib's zu: Du hast nur keinen Editor, der in der Lage ist, Textblocks
> formatrichtig an eine andere Stelle zu versetzen oder einzufügen.

Das ist in Python - wie ich bereits in epischer Breite ausgeführt habe -
nicht möglich, denn ein Block ist in Python *nicht* unabhänig von seinem
Kontext. Deswegen muß er in so einem Fall in Abhängigkeit von einem a
priori unbekannten neuen Kontext geändert werden.

In einer Sprache, die explizite Blockbegrenzer unterstützt, ist die
Position eines Blocks in einer Hierarchie von Blöcken zu jedem Zeitpunkt
durch seine Position im Text eindeutig bestimmt. In Python gibt es an
einer neuen Position n übergeordnete Blöcke und der verschobene Block
könnte an jeden von diesen angefügt werden sollen oder ein neuer
Unterblock auf Hierarchieebene n + 1 werden sollen. Davon weiß der
Computer nichts, also muß derjenige, der den Text bearbeitet, es
richten.

Wenn dazu jemanden mal was intelligenteres einfällt als «Ich schaue eine
andere Richtung und rede irgendwas daher» würde es mich sehr
interessieren.

Оlе Ѕtrеісhеr

unread,

May 4, 2021, 4:01:00 AM5/4/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
> Sieghard Schicktanz <Sieghard....@SchS.de> writes:
>> Hallo Rainer,
>>
>> Du schriebst am Sun, 02 May 2021 20:02:15 +0100:
>>
>> [Python]
>>> Weil die Einrückung allerdings von Kontext abhängig ist, ist «der Block»
>>> das ebenfalls. Allerdings sehe ich keinen Sinn darin, hier forwährend
>>> Selbverständlichkeiten in einer Diskussion, die sich halb ausschließlich
>>> darauf beschänkt, Fakten zu bestreiten zu wiederholen.
>>
>> Gib's zu: Du hast nur keinen Editor, der in der Lage ist, Textblocks
>> formatrichtig an eine andere Stelle zu versetzen oder einzufügen.
>
> Das ist in Python - wie ich bereits in epischer Breite ausgeführt habe -
> nicht möglich, denn ein Block ist in Python *nicht* unabhänig von seinem
> Kontext. Deswegen muß er in so einem Fall in Abhängigkeit von einem a
> priori unbekannten neuen Kontext geändert werden.

... was genauso automatisiert passieren kann wie mit expliziten
Blockbegrenzern.

> In einer Sprache, die explizite Blockbegrenzer unterstützt, ist die
> Position eines Blocks in einer Hierarchie von Blöcken zu jedem Zeitpunkt
> durch seine Position im Text eindeutig bestimmt. In Python gibt es an
> einer neuen Position n übergeordnete Blöcke und der verschobene Block
> könnte an jeden von diesen angefügt werden sollen oder ein neuer
> Unterblock auf Hierarchieebene n + 1 werden sollen. Davon weiß der
> Computer nichts, also muß derjenige, der den Text bearbeitet, es
> richten.

def foo(bar):
# *1*
foo0(bar+1)
# *2*

An der mit *1* gekennzeichneten Stelle gibt es genau eine mögliche
Einrückung für syntaktisch korrekten Code.

An der mit *2* gekennzeichneten Stelle muss der Editor halt die
Spaltenposition des Cursors beim Einfügen berücksichtigen und die
Einrückung des Blocks ggfs. anpassen.

> Wenn dazu jemanden mal was intelligenteres einfällt als «Ich schaue eine
> andere Richtung und rede irgendwas daher» würde es mich sehr
> interessieren.

Die Argumente kamen bereits. Du verschließt Dich ihnen allerdings.

Ole

Rainer Weikusat

unread,

May 4, 2021, 11:21:56 AM5/4/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:

[...]

>> Das ist in Python - wie ich bereits in epischer Breite ausgeführt habe -
>> nicht möglich, denn ein Block ist in Python *nicht* unabhänig von seinem
>> Kontext. Deswegen muß er in so einem Fall in Abhängigkeit von einem a
>> priori unbekannten neuen Kontext geändert werden.

[...]

>> In einer Sprache, die explizite Blockbegrenzer unterstützt, ist die
>> Position eines Blocks in einer Hierarchie von Blöcken zu jedem Zeitpunkt
>> durch seine Position im Text eindeutig bestimmt. In Python gibt es an
>> einer neuen Position n übergeordnete Blöcke und der verschobene Block
>> könnte an jeden von diesen angefügt werden sollen oder ein neuer
>> Unterblock auf Hierarchieebene n + 1 werden sollen. Davon weiß der
>> Computer nichts, also muß derjenige, der den Text bearbeitet, es
>> richten.

[...]

>> Wenn dazu jemanden mal was intelligenteres einfällt als «Ich schaue eine
>> andere Richtung und rede irgendwas daher» würde es mich sehr
>> interessieren.
>
> Die Argumente kamen bereits. Du verschließt Dich ihnen allerdings.

Es kam - auch hier wieder - ein fortwährendes, mit meiner Aussage
unzusammenhänges Gerede über automatische Einrückung beim Neuschreiben
von Code, dh (zB) der «indented text mode» von Emacs.

Darum ging's aber nicht.

Оlе Ѕtrеісhеr

unread,

May 4, 2021, 12:01:03 PM5/4/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
> Es kam - auch hier wieder - ein fortwährendes, mit meiner Aussage
> unzusammenhänges Gerede über automatische Einrückung beim Neuschreiben
> von Code, dh (zB) der «indented text mode» von Emacs.
>
> Darum ging's aber nicht.

Das hier war Deine Aussage:

>>> In Python gibt es an einer neuen Position n übergeordnete Blöcke und
>>> der verschobene Block könnte an jeden von diesen angefügt werden
>>> sollen oder ein neuer Unterblock auf Hierarchieebene n + 1 werden
>>> sollen. Davon weiß der Computer nichts, also muß derjenige, der den
>>> Text bearbeitet, es richten.

Mein Gegenargument hier lautet, dass die Hierarchieebene für jede
Spaltenposition nach einem (oder innerhalb eines) Blocks (soweit
überhaupt zulässig) eindeutig ist, und dies auch für einen Computer
erkennbar ist. Entsprechend kann er den Block auch an jeder Stelle
automatisiert einfügen.

Da muss niemand, "der den Text bearbeitet" es richten.

Ole

Rainer Weikusat

unread,

May 4, 2021, 12:29:30 PM5/4/21

to

<sarcasm>
Warum bin ich kein bißchen davon überrascht, das obiger Text schon
wieder von automatischer Einrückung für neuen Code handelt? Ich meine,
nur weil man jemandem 20x sagt «Davon rede ich nicht!» heißt das ja
nicht, daß man erwarten kann, daß er das auch nur einmal zur Kenntnis
nimmt.

Schliesslich ist sogar die eigene Meinung darüber, was jemand anderes
sagen will, jedenfalls viel wichtiger und richtiger, als jede andere
</sarcasm>

>
> Da muss niemand, "der den Text bearbeitet" es richten.

Rainer Weikusat

unread,

May 4, 2021, 12:31:52 PM5/4/21

to

Sieghard Schicktanz

unread,

May 4, 2021, 2:13:05 PM5/4/21

to

Hallo Rainer,

Du schriebst am Mon, 03 May 2021 21:22:07 +0100:

> > [Python]

> > Gib's zu: Du hast nur keinen Editor, der in der Lage ist, Textblocks
> > formatrichtig an eine andere Stelle zu versetzen oder einzufügen.
>
> Das ist in Python - wie ich bereits in epischer Breite ausgeführt habe -
> nicht möglich, denn ein Block ist in Python *nicht* unabhänig von seinem
> Kontext. Deswegen muß er in so einem Fall in Abhängigkeit von einem a

Das ist reiner Käse, bzw. zeugt von einer eindimensionalen Denk- und
Arbeitsweise. Ein _BLOCK_ ist ein ZWEIdimensionales Gebilde, mit Höhe und
Breite, das in einem ZWEIdimensionalen Kontext entsprechend positioniert
werden kann und sollte.

> priori unbekannten neuen Kontext geändert werden.

Der Kontext muß schon bekannt sein, damit dort was 'reingeschrieben werden
kann.

Und, übrigens, auch

> In einer Sprache, die explizite Blockbegrenzer unterstützt, ist die

zweidimensionale Einfügung eines kopierten Blocks von Programmzeilen
sinnvoll, weil damit auch die die menschliche kognitive Erfassung der
Struktur unterstützende Formatierung erhalten bleibt.

> In einer Sprache, die explizite Blockbegrenzer unterstützt, ist die
> Position eines Blocks in einer Hierarchie von Blöcken zu jedem Zeitpunkt

> durch seine Position im Text eindeutig bestimmt. In Python [gibt es an]

ist das genauso.

> Wenn dazu jemanden mal was intelligenteres einfällt als «Ich schaue eine
> andere Richtung und rede irgendwas daher» würde es mich sehr
> interessieren.

Dito.

Klaus von der Heyde

unread,

May 4, 2021, 2:30:45 PM5/4/21

to

Sieghard Schicktanz schrieb:

> Das ist reiner Käse, bzw. zeugt von einer eindimensionalen Denk- und
> Arbeitsweise.

Das stimmt, C ist in diesem Sinne »eindimensional«: man könnte alles ohne
Zeilenwechsel hintereinander schreiben — von Präprozessorsachen und
diesen schicken neuen Kommentaren (»//«) abgesehen.

> Ein _BLOCK_ ist ein ZWEIdimensionales Gebilde, mit Höhe
> und Breite, das in einem ZWEIdimensionalen Kontext entsprechend
> positioniert werden kann und sollte.

Das entspricht nicht dem, was ein C-Programmierer unter einem Block
versteht.

-- Klaus

Rainer Weikusat

unread,

May 4, 2021, 3:42:28 PM5/4/21

to

Sieghard Schicktanz <Sieghard....@SchS.de> writes:
> Du schriebst am Mon, 03 May 2021 21:22:07 +0100:
>
>> > [Python]
>> > Gib's zu: Du hast nur keinen Editor, der in der Lage ist, Textblocks
>> > formatrichtig an eine andere Stelle zu versetzen oder einzufügen.
>>
>> Das ist in Python - wie ich bereits in epischer Breite ausgeführt habe -
>> nicht möglich, denn ein Block ist in Python *nicht* unabhänig von seinem
>> Kontext. Deswegen muß er in so einem Fall in Abhängigkeit von einem a
>
> Das ist reiner Käse, bzw. zeugt von einer eindimensionalen Denk- und
> Arbeitsweise. Ein _BLOCK_ ist ein ZWEIdimensionales Gebilde, mit Höhe und
> Breite, das in einem ZWEIdimensionalen Kontext entsprechend positioniert
> werden kann und sollte.

In Python ist das so. In anderen Sprachen nicht. Das war das, wovon ich
die ganze Zeit geschrieben hatte.

Juergen Ilse

unread,

May 4, 2021, 5:07:32 PM5/4/21

to

Hallo,

Eben: in python laesst sich durch Aenderung der Formatierung die Semantik
aendern. In gewissem Masse war das bei den "Urgesteien" der Hochsprachen
FORTRAN und COBOL auch so. Bei spaeteren Sprachen galt es als grosse Er-
rungenschaft, diese Abhaengigkeit von der Formatierung losgeworden zu sein.
Und nun soll es bei Python eine grosse Errungenschaft sein, diesen Unfug
wieder einzufiehren? Das ist eine ueberus perverse Sichtweise.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

Rainer Weikusat

unread,

May 4, 2021, 5:33:38 PM5/4/21

to

Ironischerweise läuft das genau dasselbe hinaus, nur mit anderem
Vorzeichen. Um nochmal das bereits angeführte Beispiel zu bemühen:

------

if global_args.debug:
logger.setLevel(logging.DEBUG)
elif global_args.quiet:
logger.setLevel(logging.ERROR)

# Need to re-run logger_create with color argument
# (will be the same logger since it has the same name)
bb.msg.logger_create('bitbake-layers', output=sys.stdout, color=global_args.color)

plugins = []
tinfoil = bb.tinfoil.Tinfoil(tracking=True)
tinfoil.logger.setLevel(logger.getEffectiveLevel())
try:
tinfoil.prepare(True)
for path in ([topdir] +
tinfoil.config_data.getVar('BBPATH').split(':')):
pluginpath = os.path.join(path, 'lib', 'bblayers')
bb.utils.load_plugins(logger, plugins, pluginpath)

registered = False

------

verschieben wir also wieder denselben Block:

------

# Need to re-run logger_create with color argument
# (will be the same logger since it has the same name)
bb.msg.logger_create('bitbake-layers', output=sys.stdout, color=global_args.color)

plugins = []
tinfoil = bb.tinfoil.Tinfoil(tracking=True)
tinfoil.logger.setLevel(logger.getEffectiveLevel())
try:
tinfoil.prepare(True)
for path in ([topdir] +
tinfoil.config_data.getVar('BBPATH').split(':')):
pluginpath = os.path.join(path, 'lib', 'bblayers')
bb.utils.load_plugins(logger, plugins, pluginpath)

if global_args.debug:
logger.setLevel(logging.DEBUG)
elif global_args.quiet:
logger.setLevel(logging.ERROR)

registered = False

--------

Hier erkennt man unmittelbar folgendes Problem: Der Block-Kontext am
Zielort «weiß» leider nichts davon, daß er Whitespace in geeigneter
Menge und Position enthalten müßte, um den verschobenen Code an der
richtigen Stelle zu plazieren: 'Wir' haben also jetzt das Problem «der
Block kann nicht als solcher verschoben werden, weil sein Inhalt vom
Kontext abhängt» wegdefiniert, um es durch das Problem: «Der Block kann
nicht verschoben werden, weil der Inhalt des neuen Zielkontexts
rückwirkend vom Inhalt des neuen Blocks abhängt» zu ersetzen.

Ob man sich jetzt vorstellt, man müsse den verschobenen Block ändern,
damit er zum neuen Kontext paßt, oder den neuen Kontext, damit er zum
verschobenen Block paßt, macht offensichtlich keinen Unterschied.

:-))

Оlе Ѕtrеісhеr

unread,

May 5, 2021, 3:55:22 AM5/5/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
> Nehmen wir mal folgendes Codebeispiel:
>
> ,----
> | if global_args.debug:
> | logger.setLevel(logging.DEBUG)
> |

> | try:
> | for path in ([topdir] + ...):

> | bb.utils.load_plugins(logger, plugins, pluginpath)
> |
> | registered = False
> `----

Das ist kein korrekter Pythoncode. Zu Try gehört zwingend ein "except"
oder ein "finally". Und eine Kürzung auf den wirklich relevanten Bereich
hätte auch geholfen. Ich habe Dein Beispiel mal entsprechend angepasst.

> und ändern das (ohne Berücksichtung sinnvoller Semantik) wie folgt:
>

> | try:
> | for path in ([topdir] + ...):
> | bb.utils.load_plugins(...)
> |
> | if global_args.debug:
> | logger.setLevel(logging.DEBUG)

> |
> | registered = False
> `----
>
> Hier wurde ein Block durch Copy'n'Paste verschoben. Obiges zeigt eine
> mögliche, grammatisch gültige Änderung. Genauso gültig sind auch

Das ist keine gültige Verschiebung eines Blocks, und das ist auch für
einen Editor erkennbar: erstens ist das Try-Statement jetzt ganz
offensichtlich unvollständig (vorher hätte man wenigstens noch mit Gutem
Willen annehmen können, dass Du den Rest weggelassen hast), und zweitens
wird die Zeile "registered = False" von den übrigen Zeilen des Blocks
abgetrennt. Beides ist trivial durch einen Editor erkenn- und verhinderbar.

> ,----
> | try:
> | for path in ([topdir] + ...):
> | bb.utils.load_plugins(...)
> |
> | if global_args.debug:
> | logger.setLevel(logging.DEBUG)
> |
> | registered = False
> `----

Das ist eine korrekte Verschiebung.

> ,----
> | try:
> | for path in ([topdir] + ...):
> | bb.utils.load_plugins(...)
> |
> | if global_args.debug:
> | logger.setLevel(logging.DEBUG)
> |
> | registered = False
> `----

Das ist ebenfalls eine korrekte Verschiebung.

> ,----
> | try:
> | for path in ([topdir] + ...):
> | bb.utils.load_plugins(...)
> |
> | if global_args.debug:
> | logger.setLevel(logging.DEBUG)
> |
> | registered = False
> `----

Die ist nicht korrekt, weil die Einrückung von "registered" verändert
wurde. Auch das kann ein Editor automatisch erkennen und verhindern.

> Das bedeutet jedesmal etwas anderes und Anhaltspunkte dafür, wie der
> finale (Quell-)text nach dem verschieben des Block aussehen sollte,
> lassen sich aus dem Text nicht herleiten.

In Deinen Beispielen gibt es nur zwei "ein bißchen korrekte"
Möglichkeiten (die beide unter dem unvollständigen Try-statement
leiden). Die Entscheidung zwischen den beiden muss in Python durch die
entsprechende Einrückung erfolgen; in C-like Sprachen durch die Position
vor oder nach der Schwabbelklammer (falls überhaupt vorhanden).

BTW, wie verschiebt eigentlich ein Editor das erste Inkrement in

----------8<--------------
n += 1;

for (i = 0; i < 5; i++)
bar();
----------8<--------------

in die Schleife hinein vor das bar()?

Ole

Martin Vaeth

unread,

May 5, 2021, 4:07:18 AM5/5/21

to

Rainer Weikusat <rwei...@talktalk.net> wrote:
> Dietrich Clauss <diet...@clauss-it.com> writes:
>> Оlе Ѕtrеісhеr wrote:
>>> Ich würde die gemeinsame Einrückung eines Codeblocks
>>> nicht als Bestandteil des Blockes selber ansehen.
>>
>> Ich auch nicht, und das ist vmtl. der Knackpunkt. Vielleicht kann man
>> es so ausdrücken: In Python hat ein Block eine rechteckige Form. Der
>> Whitespace links davon gehört zum den Block umgebenden Code. Hat man
>> das verinnerlicht, so kann man in Python die Codeblöcke genauso
>> umherschieben wie in anderen Sprachen auch.
>
> Ironischerweise läuft das genau dasselbe hinaus, nur mit anderem
> Vorzeichen. Um nochmal das bereits angeführte Beispiel zu bemühen:
>
> ------
> if global_args.debug:
> logger.setLevel(logging.DEBUG)
> elif global_args.quiet:
> logger.setLevel(logging.ERROR)
>
> # Need to re-run logger_create with color argument
> # (will be the same logger since it has the same name)

> bb.msg.logger_create() # cut for USE-net linelength

>
> plugins = []
> tinfoil = bb.tinfoil.Tinfoil(tracking=True)
> tinfoil.logger.setLevel(logger.getEffectiveLevel())
> try:
> tinfoil.prepare(True)
> for path in ([topdir] +
> tinfoil.config_data.getVar('BBPATH').split(':')):
> pluginpath = os.path.join(path, 'lib', 'bblayers')
> bb.utils.load_plugins(logger, plugins, pluginpath)
>
> registered = False
> ------
>
> verschieben wir also wieder denselben Block:
>
> ------
> # Need to re-run logger_create with color argument
> # (will be the same logger since it has the same name)

> bb.msg.logger_create() # cut for USE-net linelength

>
> plugins = []
> tinfoil = bb.tinfoil.Tinfoil(tracking=True)
> tinfoil.logger.setLevel(logger.getEffectiveLevel())
> try:
> tinfoil.prepare(True)
> for path in ([topdir] +
> tinfoil.config_data.getVar('BBPATH').split(':')):
> pluginpath = os.path.join(path, 'lib', 'bblayers')
> bb.utils.load_plugins(logger, plugins, pluginpath)
>
> if global_args.debug:
> logger.setLevel(logging.DEBUG)
> elif global_args.quiet:
> logger.setLevel(logging.ERROR)
>
> registered = False
> --------
>
> Hier erkennt man unmittelbar folgendes Problem:

Nämlich, dass Du einen zur Python-Editierung untauglichen Editor
benutzt hast, oder ihn nicht benutzen kannst, wie schon vermutet
wurde.

Ein guter Python-Editor hätte den Block richtig eingerückt:
Da Du in diesem Fall den Block an einem Blockende einfügst, musst
Du in diesem Fall den Cursor nur vor dem Verschieben richtig
positionieren (damit klar ist, ob Du den eingefügten Block
innerhalb der For-Schleife willst oder nicht), und den Rest
sollte ein Python-tauglicher Editor selbst machen.

Wenn Du nicht zufällig an ein Blockende eingefügt hättest,
sondern 1,2,4, oder 5 Zeilen höher, müsstest Du nicht einmal
innerhalb der Zeile positionieren.

Diese einmalige Positionierung musst Du übrigens in z.B. C
an einem Blockende genauso machen: Je nachdem, ob Du den Cursor
vor/auf oder nach die schließende Klammer stellst, bevor Du
verschiebst. Da hast Du u.U. sogar noch das zusätzliche Problem,
dass Du im Fall eines Blockendes möglicherweise gar keine
schließenden Klammern zum Positionieren hast (wenn Du die
extrem unpraktische Einkommando=Block Syntax benutzt), und
Du vorher oder nachher manuell öffnende und schließende Klammern
einfügen musst.

Ja, ein Python-Editor muss zum korrekten Funktionieren annehmen,
dass Du einen vollständigen BLock verschiebst, sonst musst
Du manuell nacharbeiten - ebenfalls wie in C, weil auch in C
ein Editor die schließenden Klammern nicht automatisch setzen
kann, wenn Du nur einen Teilblock verschiebst.

Оlе Ѕtrеісhеr

unread,

May 5, 2021, 4:10:56 AM5/5/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:

> Dietrich Clauss <diet...@clauss-it.com> writes:
>> Ich auch nicht, und das ist vmtl. der Knackpunkt. Vielleicht kann man
>> es so ausdrücken: In Python hat ein Block eine rechteckige Form. Der
>> Whitespace links davon gehört zum den Block umgebenden Code. Hat man
>> das verinnerlicht, so kann man in Python die Codeblöcke genauso
>> umherschieben wie in anderen Sprachen auch.
>
> Ironischerweise läuft das genau dasselbe hinaus, nur mit anderem
> Vorzeichen. Um nochmal das bereits angeführte Beispiel zu bemühen:

(das Beispiel wieder auf das Wesentliche gekürzt)

> ------
> if global_args.debug:
> logger.setLevel(logging.DEBUG)
>
> try:
> for path in ([topdir] + ...):
> bb.utils.load_plugins(...)

>
> registered = False
> ------
>
> verschieben wir also wieder denselben Block:
>
> ------

> try:
> tinfoil.prepare(True)

> for path in ([topdir] + ...):
> bb.utils.load_plugins(...)
>
> if global_args.debug:
> logger.setLevel(logging.DEBUG)
>
> registered = False

> --------

Das ist syntaktisch falsch: in der Zeile, in der Du das if-statement
einfügen willst gibt es genau zwei mögliche Einrückungen, und zwar bis
Spalte 8 ("for") oder bis Spalte 12 ("bb.utils"). Das kann auch ein
Editor ohne weiteres durch Untersuchung der unmittelbaren Umgebung der
Zeile feststellen.

Die Einrückung der "registered = False"-Zeile wurde hier "irgendwie"
geändert; dafür kann man den Editor nicht verantwortlich machen (er
könnte es natürlich verhindern, da es syntaktisch falsch ist).

> Hier erkennt man unmittelbar folgendes Problem: Der Block-Kontext am
> Zielort «weiß» leider nichts davon, daß er Whitespace in geeigneter
> Menge und Position enthalten müßte, um den verschobenen Code an der
> richtigen Stelle zu plazieren:

Der Block-Kontext in der Zielzeile erlaubt genau zwei mögliche
Spaltenpositionen, an der das If-Statement eingefügt werden kann.

Der Ziel-*ort* ist dann die entsprechende Spalte in der Zielzeile, und
der wird anhand der gewünschten Struktur gewählt. Die jeder Zeile des
Blocks voranzustellenden Spaces kann der Editor dann selbst berechnen.

Ole

Ulli Horlacher

unread,

May 5, 2021, 5:26:33 AM5/5/21

to

Martin Vaeth <mar...@mvath.de> wrote:

> Nämlich, dass Du einen zur Python-Editierung untauglichen Editor

> Ein guter Python-Editor hätte den Block richtig eingerückt:

Fuer jede Programmiersprache soll man einen eigenen speziellen Editor
verwenden?!
Das ist ja NOCH bescheuerter!

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

Оlе Ѕtrеісhеr

unread,

May 5, 2021, 6:28:36 AM5/5/21

to

Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> Martin Vaeth <mar...@mvath.de> wrote:
>> Ein guter Python-Editor hätte den Block richtig eingerückt:
>
> Fuer jede Programmiersprache soll man einen eigenen speziellen Editor
> verwenden?!
> Das ist ja NOCH bescheuerter!

Es ist durchaus üblich, dass moderne Editoren die grundlegende Syntax
der bearbeiteten Sprache verstehen und berücksichtigen, z.B. bei
Formatierung, Syntaxhervorhebung usw.

Das ist überhaupt nicht bescheuert. Und es gibt kein "soll" bei der
Verwendung eines Editors. Eine Sprachunterstützung durch den Editor hat
einfach einige Vorteile und kann das Arbeiten effektiver gestalten.

Ole

Thomas Koenig

unread,

May 5, 2021, 7:34:44 AM5/5/21

to

Juergen Ilse <ne...@usenet-verwaltung.de> schrieb:

> Hallo,
>
> Dietrich Clauss <diet...@clauss-it.com> wrote:
>> Оlе Ѕtrеісhеr wrote:
>>> Ich würde die gemeinsame Einrückung eines Codeblocks
>>> nicht als Bestandteil des Blockes selber ansehen.
>>
>> Ich auch nicht, und das ist vmtl. der Knackpunkt. Vielleicht kann man
>> es so ausdrücken: In Python hat ein Block eine rechteckige Form. Der
>> Whitespace links davon gehört zum den Block umgebenden Code. Hat man
>> das verinnerlicht, so kann man in Python die Codeblöcke genauso
>> umherschieben wie in anderen Sprachen auch.
>
> Eben: in python laesst sich durch Aenderung der Formatierung die Semantik
> aendern. In gewissem Masse war das bei den "Urgesteien" der Hochsprachen
> FORTRAN und COBOL auch so.

In kleinem und unangenehmen Maße, ja.

Unschönes Beispiel:

A = ((((X + 2.313456) * X) + 1.54321403) * X - 1.23531) * X + 2.172

ist z.B. syntaktisch valides FORTRAN (in dem bis 1991
ausschließlich gültigen Quellformat, seitdem gibt es das "free
format"), gibt aber subtil falsche Ergebnisse, weil

qvr yrmgr Mnuy rvaf mh jrvg apu yvaxf enhfeüpxg, q.u. qvr Mjrv tnam
nz Raqr jveq notrfpuavggra.

Moderne Compiler warnen bei sowas.

Rainer Weikusat

unread,

May 5, 2021, 10:17:10 AM5/5/21

to

Können wir dieses sinnbefreite Gefasel über «Texteditoren» endlich mal
beenden? Das wird langsam vollkommen surreal: An der oa Textstelle gibt
es wenigstens sieben semantisch unterschiedliche Möglichkeiten, wie der
verschobene Block formatiert werden könnte (ein paar davon hatte ich in
einem anderen Posting gezeigt) und kein Texteditor der Welt kann die
Gedanken seines Benutzers lesen, um herauzufinden, welche dieser
Möglichkeiten hier beabsichtigt ist.

Man kommt allmählich gradezu zu der Ansicht, das Python nur von Robotern
mit sehr primitive Steuerprogrammen benutzt wird, deren Menge von
mögliche Reaktionen auf beliebige externe Stimuli begrenzt und sehr
klein ist.

Übrigens hat das auch weiterhin nichts mit der Aussage, die ich hier
mache, zu tun. Da geht es um Rückwärtsabhängigkeiten zwischen
Codeblöcken auf unterschiedlichen Hierarchie-Ebenen, die dem
«klassischen» Modell eines strukturierten Programmes als sequentielle
Folge prinzipell unabhängiger Berechnungschritte widersprechen.

Aber sowas ist im Program von Python-Robotern wohl überhaupt gar nicht
vorgesehen.

Оlе Ѕtrеісhеr

unread,

May 5, 2021, 11:54:02 AM5/5/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
> Können wir dieses sinnbefreite Gefasel über «Texteditoren» endlich mal
> beenden? Das wird langsam vollkommen surreal: An der oa Textstelle gibt
> es wenigstens sieben semantisch unterschiedliche Möglichkeiten, wie der
> verschobene Block formatiert werden könnte (ein paar davon hatte ich in
> einem anderen Posting gezeigt)

Es gibt in Deinem Beispiel bei Einfügung in einer **Zeile** genau zwei
Möglichkeiten, die syntaktisch halbwegs korrekt sind.

Bei Einfügung an einer **Position**, die sowohl Zeile als auch Spalte
umfasst, gibt es maximal **eine** korrekte Möglichkeit.

> und kein Texteditor der Welt kann die Gedanken seines Benutzers lesen,

^^^^^^^^^^
Was denn nun? Redest Du über Texteditoren oder nicht?

> um herauzufinden, welche dieser Möglichkeiten hier beabsichtigt ist.

> Übrigens hat das auch weiterhin nichts mit der Aussage, die ich hier
> mache, zu tun. Da geht es um Rückwärtsabhängigkeiten zwischen
> Codeblöcken auf unterschiedlichen Hierarchie-Ebenen, die dem
> «klassischen» Modell eines strukturierten Programmes als sequentielle
> Folge prinzipell unabhängiger Berechnungschritte widersprechen.

Wie schon mehrfach geschrieben: wenn man die gemeinsame Einrückung aller
Codezeilen eines Codeblocks als von diesem getrennt sieht, ist das kein
Problem:

Die Zeilen

--------- 1 --- 1 --- 1 -----------
a = 1
b = 2
--------- 1 --- 1 --- 1 -----------

können aufgefasst werden als Codeblock

--------- 2 --- 2 --- 2 -----------
a = 1
b = 2
--------- 2 --- 2 --- 2 -----------

und einer gemeinsamen Einrückung von 4 Spaces. Der Codeblock (also das,
was mit -- 2 --- 2 -- gerahmt ist) hat keine Abhängigkeit von den
umgebenden Blöcken.

Ole

Martin Vaeth

unread,

May 6, 2021, 4:47:42 AM5/6/21

to

Rainer Weikusat <rwei...@talktalk.net> schrieb:

>
> Können wir dieses sinnbefreite Gefasel über «Texteditoren» endlich mal
> beenden?

Nein, denn genau das ist der Punkt, über den Du offensichtlich irrst:

> Das wird langsam vollkommen surreal: An der oa Textstelle gibt
> es wenigstens sieben semantisch unterschiedliche Möglichkeiten, wie der
> verschobene Block formatiert werden könnte

Und *genau eine*, die die alte und neue Blockstruktur erhält, wenn die
Zielspalte festgelegt wird.
Und das ist *in allen Beispielen* der Fall (wie gesagt: Unter der
Annahme, dass man einen ganze Block markiert).

Wenn nur die Ziel*zeile* festgelegt wird, kann es in *einigen* Beispielen
mehr semantisch sinnvolle Möglichkeitgen geben (im gegebenen Beispiel
genau zwei) - nämlich genau dann, wenn die Zielzeile im Kontext das Ende
eines oder mehrerer Blöcke darstellt.
(Und wie gesagt muss man dann auch in C entweder vor oder
nach die schließende Klammer gehen, was je nach C-Stil ebenfalls
das Festlegen der Zielposition innerhalb der Zeile erfordern kann).

Martin Vaeth

unread,

May 6, 2021, 4:53:09 AM5/6/21

to

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Martin Vaeth <mar...@mvath.de> wrote:
>
>> Nämlich, dass Du einen zur Python-Editierung untauglichen Editor
>
>> Ein guter Python-Editor hätte den Block richtig eingerückt:
>
> Fuer jede Programmiersprache soll man einen eigenen speziellen Editor
> verwenden?!

Es ist in der Tat für *jede* Programmiersprache sinnvoll, einen Editor
zu benutzen, der genau diese Sprache unterstützt:
Wenn Du z.B. in C eine Block von einer anderen Hierarchieebene
verschiebst, wirst Du Dich da entweder ebenfalls auf einen Editor
verlassen oder alle Einrückungen von Hand nachkorrigieren müssen
(oder mit irreführenden Einrückungen leben müssen, was zumindest
bei größeren Projekten keine diskutable Option ist).

Martin Vaeth

unread,

May 6, 2021, 5:01:57 AM5/6/21

to

Rainer Weikusat <rwei...@talktalk.net> schrieb:

>
> Man kommt allmählich gradezu zu der Ansicht, das Python nur von Robotern
> mit sehr primitive Steuerprogrammen benutzt wird

Abgesehen von diesem unangemessenen ad-hominem-Angriff kann ich Dir sagen,
dass ich Python für eine fürchterliche Programmiersprache und pep8 für
noch fürchterlicher halte (Tab statt 2 Spaces, mehrere Tabs beim
Funktionsheader usw. sorgen zusammen mit Begrenzung auf 80 Zeichen dafür,
dass sich unangemessen viel Code in den letzten paar Spalten zwecks Umbruch
tumelt und vieles gar nicht schreibbar ist).
Aber das Fehlen expliziter Blockbegrenzer gehört nicht zu meinen
Kritikpunkten: Das ist eine reine Geschmacksfrage, und über den lässt sich
bekanntlich streiten. Deine geäußerten Behauptungen dazu sind schlichtweg
falsch.

Dietrich Clauss

unread,

May 6, 2021, 5:08:08 AM5/6/21

to

*So* eine Art semantische Wirksamkeit der Formatierung will man einfach
nur loswerden, das ist klar. Mit Python hat das aber nichts zu tun.

Dietrich Clauss

unread,

May 6, 2021, 5:08:08 AM5/6/21

to

Die Abhängigkeit von der Formatierung ist man nie losgeworden. Sie ist
da, nicht technisch, aber de-facto, und darauf kommt es an. Halbwegs
lesbarer Code ist immer formatiert, und die Formatierung muß mit der
Semantik übereinstimmen. Man muß formatieren, ob manuell oder mit Hilfe
von automatischen Werkzeugen, und man kann es falsch machen, und heraus
kommen Fehler, die sich schon per Sprachdesign hätten vermeiden lassen.

Die Designer von Python haben hier einfach eins und eins zusammengezählt
und haben der Formatierung eine Bedeutung gegeben, wodurch die Syntax
vereinfacht werden konnte. Man verliert nichts, und man vermeidet
sowas:

-----------------------------8<---------------------------
void a(){} void b(){} void c(){} void d(){} void x(){}
int z(){return 0;}

void main()
{
// 1
while (z())
a();
b();
x();

// 2
while (z()); {
a();
b();
}

// 3
while (z())
a(); {
b();
c();
}

// 3a
while (z())
a();
{ b();
c();
}

// 3b
while (z()) {
a();
b();
} c();

x();

// 4
while (z()) {
a();
b();}{c();
d();
}
}
-----------------------------8<---------------------------

Und das sind nur ein paar Beispiele, die mir auf die Schnelle
eingefallen sind.

In Python sieht das so aus:

----------8<-------------
def a(): pass
def b(): pass
def c(): pass
def x(): pass
def z(): return False

while z():
a()
b()
c()
x()
----------8<-------------

Versehentliches Falschsetzen von Blockbegrenzern ist unmöglich, da es
keine Blockbegrenzer gibt. Stattdessen kann man natürlich falsch
einrücken. Das kann zu verändertem Verhalten führen, was dann aber auch
sofort sichtbar ist. Ein tückisches "sieht so aus, tut aber was
anderes" wird per Sprachdesign ausgeschlossen.

Und als IMHO nicht ganz unbedeutenden Nebeneffekt beendet man die nicht
enden wollende Diskussion darüber, wo denn nun bei ordentlich
formatiertem Code die geschweiften Klammern plaziert werden sollen, auf
sehr elegante Weise.

Ob das nun eine große Errungenschaft ist oder perverser Unfug oder
irgendwas dazwischen, das muß jeder für sich selbst bewerten. Die
Argumente Pro-Unfug, die in diesem Thread bisher vorgebracht wurden,
überzeugen mich jedenfalls nicht.

Thomas Koenig

unread,

May 6, 2021, 6:19:21 AM5/6/21

to

Martin Vaeth <mar...@mvath.de> schrieb:

> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> Martin Vaeth <mar...@mvath.de> wrote:
>>
>>> Nämlich, dass Du einen zur Python-Editierung untauglichen Editor
>>
>>> Ein guter Python-Editor hätte den Block richtig eingerückt:
>>
>> Fuer jede Programmiersprache soll man einen eigenen speziellen Editor
>> verwenden?!
>
> Es ist in der Tat für *jede* Programmiersprache sinnvoll, einen Editor
> zu benutzen, der genau diese Sprache unterstützt:
> Wenn Du z.B. in C eine Block von einer anderen Hierarchieebene
> verschiebst, wirst Du Dich da entweder ebenfalls auf einen Editor
> verlassen

Der sich wiederum auf syntaktisch eindeutige Regeln verlassen kann,
d.h. da kann nichts passieren.

>oder alle Einrückungen von Hand nachkorrigieren müssen

Mittlerweile existiert clang-format, um sowas zu automatisieren.
Da clang den C-Code dafür tatsächlich parst, ist das nach den
Regeln von C auch mit einem verschobenen Block automatisiert möglich.

Bei Python geht das nicht.

Martin Vaeth

unread,

May 6, 2021, 7:10:22 AM5/6/21

to

Thomas Koenig <tko...@netcologne.de> wrote:
> Martin Vaeth <mar...@mvath.de> schrieb:

>>
>> Es ist in der Tat für *jede* Programmiersprache sinnvoll, einen Editor
>> zu benutzen, der genau diese Sprache unterstützt:
>> Wenn Du z.B. in C eine Block von einer anderen Hierarchieebene
>> verschiebst, wirst Du Dich da entweder ebenfalls auf einen Editor
>> verlassen
>
> Der sich wiederum auf syntaktisch eindeutige Regeln verlassen kann,
> d.h. da kann nichts passieren.

Wie in Python, nur sind halt die Syntax-Regeln anders.

> Mittlerweile existiert clang-format, um sowas zu automatisieren.
> Da clang den C-Code dafür tatsächlich parst, ist das nach den
> Regeln von C auch mit einem verschobenen Block automatisiert möglich.
>
> Bei Python geht das nicht.

Korrekt, bei Python musst Du das beim Verschieben tun - bei C kann
man auch einen Murks-Editor wählen und sich darauf verlassen, dass
man den Müll im Nachhinein automatisch repariert bekommen. Für Fans
von Murks-Editoren sind das in der Tat schlechte Neuigkeiten.

Dietrich Clauss

unread,

May 6, 2021, 9:08:08 AM5/6/21

to

Äpfel vs. Birnen.

Wie schon nebenan bemerkt, schiebt man bei Python einen Codeblock an die
gewünschte Position - Zeile:Spalte. Dann stimmen auch alle Einrückungen
schon, und Klammern braucht es keine. Da muß überhaupt nichts
nachkorrigiert werden, weder automatisch noch manuell. "Bei Python geht
das nicht" ist sogesehen zwar richtig, spielt aber keine Rolle, denn bei
Python ist das schlicht überflüssig.

Bei C macht man es entweder genauso, oder man verwirft die Indent des
Blocks zunächst und stellt sie dann, womöglich automatisiert, wieder
her. Das ist äquivalent.

Ein anderes Problem ist Code mit komplett falschen oder fehlenden
Einrückungen. Solcher C-Code kann automatisch formatiert werden.
Solcher Pythoncode ist jedoch äquivalent zu C-Code mit falschen oder
fehlenden geschweiften Klammern. Da geht nichts automatisch zu
korrigieren, weder in der einen noch in der anderen Sprache.

Оlе Ѕtrеісhеr

unread,

May 6, 2021, 9:21:09 AM5/6/21

to

Dietrich Clauss <diet...@clauss-it.com> writes:
> Wie schon nebenan bemerkt, schiebt man bei Python einen Codeblock an die
> gewünschte Position - Zeile:Spalte. Dann stimmen auch alle Einrückungen
> schon, und Klammern braucht es keine. Da muß überhaupt nichts
> nachkorrigiert werden, weder automatisch noch manuell.

Naja, "fast": Man *muss* natürlich nicht, aber wenn man seinen Code auch
PEP8-konform haben will, gilt das hier:

| Maximum Line Length
|
| Limit all lines to a maximum of 79 characters.
|
| For flowing long blocks of text with fewer structural restrictions
| (docstrings or comments), the line length should be limited to 72
| characters.

Ole

Juergen Ilse

unread,

May 8, 2021, 11:23:21 PM5/8/21

to

Hallo,

Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>> Können wir dieses sinnbefreite Gefasel über «Texteditoren» endlich mal
>> beenden? Das wird langsam vollkommen surreal: An der oa Textstelle gibt
>> es wenigstens sieben semantisch unterschiedliche Möglichkeiten, wie der
>> verschobene Block formatiert werden könnte (ein paar davon hatte ich in
>> einem anderen Posting gezeigt)
>
> Es gibt in Deinem Beispiel bei Einfügung in einer **Zeile** genau zwei
> Möglichkeiten, die syntaktisch halbwegs korrekt sind.

2 Moeglichkeiten ist doppelt so viel wie akzeptabel waere ...
Es ist einfach nur eine ueble Idee, Formatierung zu einem Teil der
Semantik zu machen. Warum ist diese einfache Erkenntnis so schnell
wieder verloren gegangen?

Tschuess,
Juergen Ilse (juergenqusenet-verwaltung.de)

Оlе Ѕtrеісhеr

unread,

May 9, 2021, 4:33:16 AM5/9/21

to

Juergen Ilse <ne...@usenet-verwaltung.de> writes:
> Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:
>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>> Können wir dieses sinnbefreite Gefasel über «Texteditoren» endlich mal
>>> beenden? Das wird langsam vollkommen surreal: An der oa Textstelle gibt
>>> es wenigstens sieben semantisch unterschiedliche Möglichkeiten, wie der
>>> verschobene Block formatiert werden könnte (ein paar davon hatte ich in
>>> einem anderen Posting gezeigt)
>>
>> Es gibt in Deinem Beispiel bei Einfügung in einer **Zeile** genau zwei
>> Möglichkeiten, die syntaktisch halbwegs korrekt sind.
>
> 2 Moeglichkeiten ist doppelt so viel wie akzeptabel waere ...

Du hast schlicht den Rest meines Textes weggeschnitten:

>> Bei Einfügung an einer **Position**, die sowohl Zeile als auch Spalte
>> umfasst, gibt es maximal **eine** korrekte Möglichkeit.

Es ist (wenn man an einer bestimmten Position einfügt) genau eine
syntaktisch korrekte Weise, dies zu tun.

> Es ist einfach nur eine ueble Idee, Formatierung zu einem Teil der
> Semantik zu machen. Warum ist diese einfache Erkenntnis so schnell
> wieder verloren gegangen?

Die Idee, Semantik und Formatierung unabhängig zu machen ist halt auch
nicht das Gelbe vom Ei und erfordert Hilfsmittel, sehr geschulte Augen
oder zusätzliche Richtlinien für die Erkennung der Fallen:

while (foo());
bar();

if (foo)
if (bar)
zoo();
else
zar();

und so weiter. "Formatierung ist Semantik" vermeidet das.

Ole

Martin Vaeth

unread,

May 9, 2021, 9:41:51 AM5/9/21

to

Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
> Hallo,
>
> Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:
>> Rainer Weikusat <rwei...@talktalk.net> writes:
>>> Können wir dieses sinnbefreite Gefasel über «Texteditoren» endlich mal
>>> beenden? Das wird langsam vollkommen surreal: An der oa Textstelle gibt
>>> es wenigstens sieben semantisch unterschiedliche Möglichkeiten, wie der
>>> verschobene Block formatiert werden könnte (ein paar davon hatte ich in
>>> einem anderen Posting gezeigt)
>>
>> Es gibt in Deinem Beispiel bei Einfügung in einer **Zeile** genau zwei
>> Möglichkeiten, die syntaktisch halbwegs korrekt sind.
>
> 2 Moeglichkeiten ist doppelt so viel wie akzeptabel waere ...

... und deswegen hast Du den entscheidenden zweiten Teil der Aussage -
dass man Eindeutigkeit bekommt (und nicht nur in diesem Beispiel, sondern
*immer*), wenn man vor dem Einfügen die richtige *Spalte* und nicht nur
die richtige Zeile als "Zielpunkt" wählt - einfach weggelassen.

Dass man die Zielspalte angeben muss, ist gerade für Programmiersprachen
mit Start-/Endeklammerung übrigens nichts neues. Hier ein typisches
Beispiel in Lisp, einer Sprache, der man wirklich nicht vorwerfen
kann, *zuwenige* Klammern zu benutzen:

(when (eq 'light mode)
(rotatef base00 base0))

Wenn Du in Lisp einen Block verschieben willst, aber nur die Zielzeile
wählen willst, gäbe es in der zweiten Zeile sage und schreibe 5
(eigentlich sogar 7) Möglichkeiten des sinnvollen Verschiebens.
Und die Zahl ist hier sogar unrealistische klein, da es nur ein
Minimal-Codeschnipsel ist.
Darauf zu beharren, dass eine Sprache so gestaltet sein müsse, dass
man in typischem Code einen Block ohne Angabe der Zielspalte verschieben
kann, wäre also vollkommen absurd.

Rainer Weikusat

unread,

May 9, 2021, 12:44:49 PM5/9/21

to

Martin Vaeth <mar...@mvath.de> writes:
> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:

[...]

> (when (eq 'light mode)
> (rotatef base00 base0))
>
> Wenn Du in Lisp einen Block verschieben willst, aber nur die Zielzeile
> wählen willst, gäbe es in der zweiten Zeile sage und schreibe 5
> (eigentlich sogar 7) Möglichkeiten des sinnvollen Verschiebens.

In Lisp haben Konzepte wie "Zeile" und "Spalte" keine semantische
Bedeutung: Entscheidend ist, an welcher "logischen" Stelle eines geklammerten
Ausdrucks etwas eingefuegt wird. Damit ist - vollkommen unabhaengig von
der Textformatierung - seine Position in der Blockhierarchie eindeutig
definiert.

Das ist bei anderen Sprachen, die geklammerte Bloecke benutzen,
dasselbe: In C endet ein Block mit der }, welches sich auf der selben
Klammerebene wir die oeffnende { befindet. Was davor kommt, ist im
Block, was dahinter steht, ausserhalb.

Martin Vaeth

unread,

May 9, 2021, 2:01:12 PM5/9/21

to

Rainer Weikusat <rwei...@talktalk.net> wrote:
> Martin Vaeth <mar...@mvath.de> writes:
>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>
> [...]
>
>
>> (when (eq 'light mode)
>> (rotatef base00 base0))
>>
>> Wenn Du in Lisp einen Block verschieben willst, aber nur die Zielzeile
>> wählen willst, gäbe es in der zweiten Zeile sage und schreibe 5
>> (eigentlich sogar 7) Möglichkeiten des sinnvollen Verschiebens.
>
> In Lisp haben Konzepte wie "Zeile" und "Spalte" keine semantische
> Bedeutung

Das ist beim Editieren eines konkreten Codes völlig wurscht: Zum
Einfügen eines Blocks mit einem Editor muss irgendwie die korrekte
Zeile+Spalte im existierenden Code spezifiziert werden. Ob Du die
Stelle im Editor mit Klammersuche oder anderen Mitteln findest, ist
irrelevant.
Die korrekte Stelle ergibt sich wie in Python aus dem Kontext - bei
Python sogar *garantiert* optisch leicht erkennbar, bei anderen
Sprachen muss man statt dessen vorsichtig "manuell" jedes Zeichen
parsen, möglicherweise sogar Zeichen, die sich gar nicht mehr auf
der betrachteten Bildschirmseite befinden.

> Entscheidend ist, an welcher "logischen" Stelle eines geklammerten
> Ausdrucks etwas eingefuegt wird.

Wie in Python: Der Cursor muss zum Einfügen eines Blocks an der
korrekten *logischen* Stelle sein.

> Das ist bei anderen Sprachen, die geklammerte Bloecke benutzen,
> dasselbe: In C endet ein Block mit der }, welches sich auf der selben
> Klammerebene wir die oeffnende { befindet. Was davor kommt, ist im
> Block, was dahinter steht, ausserhalb.

Gähn. Meinst Du wirklich, das weiß hier jemand nicht?

Rainer Weikusat

unread,

May 9, 2021, 2:10:05 PM5/9/21

to

Martin Vaeth <mar...@mvath.de> writes:
> Rainer Weikusat <rwei...@talktalk.net> wrote:
>> Martin Vaeth <mar...@mvath.de> writes:
>>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>>
>> [...]
>>
>>
>>> (when (eq 'light mode)
>>> (rotatef base00 base0))
>>>
>>> Wenn Du in Lisp einen Block verschieben willst, aber nur die Zielzeile
>>> wählen willst, gäbe es in der zweiten Zeile sage und schreibe 5
>>> (eigentlich sogar 7) Möglichkeiten des sinnvollen Verschiebens.
>>
>> In Lisp haben Konzepte wie "Zeile" und "Spalte" keine semantische
>> Bedeutung
>

> Das ist beim Editieren [...]

«Texteditor, die 521te!»

[...]

>> Das ist bei anderen Sprachen, die geklammerte Bloecke benutzen,
>> dasselbe: In C endet ein Block mit der }, welches sich auf der selben
>> Klammerebene wir die oeffnende { befindet. Was davor kommt, ist im
>> Block, was dahinter steht, ausserhalb.
>
> Gähn. Meinst Du wirklich, das weiß hier jemand nicht?

Augenscheinlich ja. Sonst hättest Du nämlich im dem Posting, auf das ich
geanwortet habe, nicht von «Zeilen» und «Spalten» als semantischen
Einheiten geschrieben.

Оlе Ѕtrеісhеr

unread,

May 9, 2021, 3:27:38 PM5/9/21

to

So what? In Python ist die Formatierung Teil der logischen Struktur, und
das hat den Vorteil, dass man die logische Struktur visuell erfassen
kann, was in C o.ä. nicht der Fall ist. Beides hat seine Vor- und
Nachteile, aber es ist eben nicht so, dass bestimmte
Bearbeitungsmöglichkeiten in Python nicht genauso automatisch erfolgen
können wie in z.B. C (und das war, was Du behauptet hattest).

Nebenbei ist C durch den Preprozessor noch viel schlimmer dran. Die in
meinem K&R dokumentierte Schweinerei ist z.B.

#define begin {
#define end }

was man gerne noch durch ein paar #if's garnieren kann; dann ist nämlich
die Blockstruktur zur Editierzeit gar nicht mehr so eindeutig.

Anderes, böses (und schon in freier Wildbahn gesehenes) Beispiel ist

#if foo
#define CONDITION if (x > 9)
#else
#define CONDITION

…
CONDITION
bar();

In C gilt nämlich die Blockstruktur *nach* dem Präprozessor, und dessen
Abarbeitung ist zur Editierzeit nicht notwendig eindeutig.

Viel Spaß mit der Blockstruktur!

Ole

Rainer Weikusat

unread,

May 9, 2021, 3:58:59 PM5/9/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>> Martin Vaeth <mar...@mvath.de> writes:
>>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>>
>> [...]
>>
>>
>>> (when (eq 'light mode)
>>> (rotatef base00 base0))
>>>
>>> Wenn Du in Lisp einen Block verschieben willst, aber nur die Zielzeile
>>> wählen willst, gäbe es in der zweiten Zeile sage und schreibe 5
>>> (eigentlich sogar 7) Möglichkeiten des sinnvollen Verschiebens.
>>
>> In Lisp haben Konzepte wie "Zeile" und "Spalte" keine semantische
>> Bedeutung: Entscheidend ist, an welcher "logischen" Stelle eines geklammerten
>> Ausdrucks etwas eingefuegt wird. Damit ist - vollkommen unabhaengig von
>> der Textformatierung - seine Position in der Blockhierarchie eindeutig
>> definiert.
>>
>> Das ist bei anderen Sprachen, die geklammerte Bloecke benutzen,
>> dasselbe: In C endet ein Block mit der }, welches sich auf der selben
>> Klammerebene wir die oeffnende { befindet. Was davor kommt, ist im
>> Block, was dahinter steht, ausserhalb.
>
> So what? In Python ist die Formatierung Teil der logischen Struktur, und
> das hat den Vorteil, dass man die logische Struktur visuell erfassen
> kann, was in C o.ä. nicht der Fall ist.

... und es hat außerdem den Effekt --- warum kommt es mir nur so vor, als
hätte ich das schon mal geschrieben --- das Python nicht wirklich eine
blockstrukturierte Sprache ist, weil Codeblöcke auf unteren
Hierarchiebenen von dem Code in oberen Hierarchieebenen abhängig sind.

Ein C-Programm (gilt auch für jede andere Sprache mit expliziten
Blockbegrenzern) besteht aus einer Folge von syntaktisch voneinander
unabhängigen Anweisungen. Manch dieser Anweisungen könne sogenannte
«compound statements», dh sie enthalten weitere Anweisungen. Die sind
aber wiederrum unabhänging voneinander und auch unabhängig von dem
Block, in dem sie enthalten sind: Jede Anweisung eines C-Program kann an
jede andere Position verschoben werden ohne daß sich an der
grammatischen Korrektheit des Programmes dadurch etwas ändern würde.

Den "Textbearbeitung"-Teil ignoriere ich mal.

Martin Vaeth

unread,

May 9, 2021, 4:06:00 PM5/9/21

to

Rainer Weikusat <rwei...@talktalk.net> schrieb:

> Martin Vaeth <mar...@mvath.de> writes:
>> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>> Martin Vaeth <mar...@mvath.de> writes:
>>>> Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>>>
>>> [...]
>>>
>>>
>>>> (when (eq 'light mode)
>>>> (rotatef base00 base0))
>>>>
>>>> Wenn Du in Lisp einen Block verschieben willst, aber nur die Zielzeile
>>>> wählen willst, gäbe es in der zweiten Zeile sage und schreibe 5
>>>> (eigentlich sogar 7) Möglichkeiten des sinnvollen Verschiebens.
>>>
>>> In Lisp haben Konzepte wie "Zeile" und "Spalte" keine semantische
>>> Bedeutung
>>
>> Das ist beim Editieren [...]
>
> «Texteditor, die 521te!»

Ja, darum ging es: Um die (falsche) Behauptung, Python sei auch mit
einem dafür geeigneten Editor schwerer zu editieren, als andere Sprachen.
Alle dazu geäußerten "Begründungen" wurden widerlegt.
Jetzt gab es erneute Rettungsversuche für die Falschbehauptung durch ein
unvollständiges (und damit sinnentstellendes) Zitat. Der allerneueste
Rettungsversuch ist jetzt offensichtlich Aufbauen eines trivialen
Strohmanns und Worklauberei:

>>> Das ist bei anderen Sprachen, die geklammerte Bloecke benutzen,
>>> dasselbe: In C endet ein Block mit der }, welches sich auf der selben
>>> Klammerebene wir die oeffnende { befindet. Was davor kommt, ist im
>>> Block, was dahinter steht, ausserhalb.
>>
>> Gähn. Meinst Du wirklich, das weiß hier jemand nicht?
>
> Augenscheinlich ja. Sonst hättest Du nämlich im dem Posting, auf das ich
> geanwortet habe, nicht von «Zeilen» und «Spalten» als semantischen
> Einheiten geschrieben.

Meine Editoren benutzen jedenfalls Cursorpositionen zum Blockverschieben.
Und zum Thema "semantischen Einheiten" habe ich vorher ebenfalls
ausdrücklich geschrieben, dass es vollkommen schnuppe ist, ob diese
Cursorposition vorher per Klammersuche oder mit anderen (sementischen)
Funktionen des Editors gefunden wurden (ich vergaß dabei zu erwähnen:
In einem Python-tauglichen Editor gibt es natürlich genauso diese
semantischen Funktionen, wie die schnelle Möglichkeit, an
Blockanfang/-ende zu springen, o.ä.)
Natürlich wurde dieser entscheidende Teil wieder nicht zitiert, denn
sonst wäre ja der Strohmann zu offensichtlich.
Bei diesem Diskussionsstil ist für mich hier EOD.

Martin Vaeth

unread,

May 9, 2021, 4:39:52 PM5/9/21

to

Rainer Weikusat <rwei...@talktalk.net> wrote:
>
> ... und es hat außerdem den Effekt --- warum kommt es mir nur so vor, als
> hätte ich das schon mal geschrieben ---

Gähn. Durch Wiederholen von Unsinn wird der nicht richtiger.

> das Python nicht wirklich eine blockstrukturierte Sprache ist

Ein Block ist ein semantisches Konzept. Natürlich wird ein
Block *auch* syntaktisch gekennzeichnet. Selbstverständlich
*hat* Python Blöcke, und selbstverständlich ist deren
syntaktische Kennzeichung klar, und die Syntax ist so gewählt,
dass sie im Gegensatz zu anderen Sprachen *garantiert* optisch
schnell erfassbar ist.

> weil Codeblöcke auf unteren Hierarchiebenen von dem Code
> in oberen Hierarchieebenen abhängig sind.

Ja, in Python ist die Block-Syntax nicht kontextfrei.
Diese Trivialität hat nie jemand bestritten. Und!?

> Jede Anweisung eines C-Program kann an jede andere Position
> verschoben werden ohne daß sich an der grammatischen Korrektheit
> des Programmes dadurch etwas ändern würde.

Und diese Eigenschaft ist von so sagenhafter praktischer Bedeutung,
weil ...!?
Mit dem Schreiben oder Wiederverwenden von Code durch Menschen hat
Deiner Meinung nach die Frage offensichtlich nichts zu tun:

Rainer Weikusat

unread,

May 9, 2021, 5:09:05 PM5/9/21

to

Martin Vaeth <mar...@mvath.de> writes:
> Rainer Weikusat <rwei...@talktalk.net> wrote:
>>
>> ... und es hat außerdem den Effekt --- warum kommt es mir nur so vor, als
>> hätte ich das schon mal geschrieben ---
>
> Gähn. Durch Wiederholen von Unsinn wird der nicht richtiger.

Etwas als Unsinn zu bezeichnen, dem man im folgenden zustimmt ist
... ähh ... Unsinn.

>
>> das Python nicht wirklich eine blockstrukturierte Sprache ist

>> weil Codeblöcke auf unteren Hierarchiebenen von dem Code
>> in oberen Hierarchieebenen abhängig sind.

- Zusammenhang wiederhergestellt -

> Ein Block ist ein semantisches Konzept. Natürlich wird ein
> Block *auch* syntaktisch gekennzeichnet. Selbstverständlich
> *hat* Python Blöcke, und selbstverständlich ist deren
> syntaktische Kennzeichung klar, und die Syntax ist so gewählt,
> dass sie im Gegensatz zu anderen Sprachen *garantiert* optisch
> schnell erfassbar ist.
>

> Ja, in Python ist die Block-Syntax nicht kontextfrei.
> Diese Trivialität hat nie jemand bestritten. Und!?

,----
| One of the most powerful mechanisms for program structuring in A L G O L 60
| is the block
|
| [...]
|
| It has the following useful properties from the standpoint of concept
| modelling.
|
| [...]
|
| (2) Decomposition. A block where only local quantities are referenced is a
| completely selfcontained program component, which will function as
| specified in any context.
`----
[Structured Programming/ III. Hierarchical Program Structures/ OLE-JOHAN
DAHL AND C. A. R. HOARE/ p. 178]

Da die Python-Blocksyntax nicht kontextunabhängig ist, haben
Python-Blöcke, im Gegensatz zu Blöcken in anderen Sprache, die
Eigenschaft «will function as specified in any context» nicht.

>> Jede Anweisung eines C-Program kann an jede andere Position
>> verschoben werden ohne daß sich an der grammatischen Korrektheit
>> des Programmes dadurch etwas ändern würde.
>
> Und diese Eigenschaft ist von so sagenhafter praktischer Bedeutung,
> weil ...!?

Es ist mal eine Eigenschaft. Keine Ahnung, ob sie von praktischer
Bedeutung ist, denn bislang habe ich Python-Code nur sehr punktuell
geändert, aber noch nie (eine größere Menge davon) selber geschrieben.

Оlе Ѕtrеісhеr

unread,

May 9, 2021, 5:29:03 PM5/9/21

to

Rainer Weikusat <rwei...@talktalk.net> writes:
>> So what? In Python ist die Formatierung Teil der logischen Struktur, und
>> das hat den Vorteil, dass man die logische Struktur visuell erfassen
>> kann, was in C o.ä. nicht der Fall ist.
>
> ... und es hat außerdem den Effekt --- warum kommt es mir nur so vor, als
> hätte ich das schon mal geschrieben --- das Python nicht wirklich eine
> blockstrukturierte Sprache ist, weil Codeblöcke auf unteren
> Hierarchiebenen von dem Code in oberen Hierarchieebenen abhängig sind.

Das hattest Du geschrieben. Und ich hatte darauf entgegnet, dass man die
Codezeilen

----------- 1 ------------------

a = 1
b = 2

----------- 1 ------------------

auffassen kann als den Codeblock

----------- 2 ------------------

a = 1
b = 2

----------- 2 ------------------

und einer Einrückung von 4 Leerzeichen. Der Codeblock (also das, was mit
"--- 2 ---" markiert ist, ist nicht abhängig von "Code in oberen
Hierarchieebenen".

Darauf hattest Du nichts mehr entgegnet.

> Ein C-Programm (gilt auch für jede andere Sprache mit expliziten
> Blockbegrenzern) besteht aus einer Folge von syntaktisch voneinander
> unabhängigen Anweisungen. Manch dieser Anweisungen könne sogenannte
> «compound statements», dh sie enthalten weitere Anweisungen. Die sind
> aber wiederrum unabhänging voneinander und auch unabhängig von dem
> Block, in dem sie enthalten sind:

... nur dass in C eben die Statements erst während der Kompilation
feststehen. Was für die Bearbeitung von C-Code und für dessen Verständnis
durch Humanoide nicht eben vorteilhaft ist.

> Jede Anweisung eines C-Program kann an jede andere Position verschoben
> werden ohne daß sich an der grammatischen Korrektheit des Programmes
> dadurch etwas ändern würde.

So?

x = 1;
if (foo)
y++;
else
y--;

verschiebe mal bitte die erste Zeile vor das y++; und sage mir, ob das
noch "grammatisch" korrekter C-Code ist.

Ole

Martin Vaeth

unread,

May 10, 2021, 6:10:15 AM5/10/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>

> Das hattest Du geschrieben. Und ich hatte darauf entgegnet, dass man die
> Codezeilen
>
> ----------- 1 ------------------
> a = 1
> b = 2
> ----------- 1 ------------------
>
> auffassen kann als den Codeblock
>
> ----------- 2 ------------------
> a = 1
> b = 2
> ----------- 2 ------------------
>
> und einer Einrückung von 4 Leerzeichen. Der Codeblock (also das, was mit
> "--- 2 ---" markiert ist, ist nicht abhängig von "Code in oberen
> Hierarchieebenen".

Da muss man schon fair sein: Die *Syntax*, die einen Block markiert,
ist definitiv kontextabhängig, und das ist ganz klar ein *Unterschied*
zu vielen anderen Sprachen.
Nur ist Kontextunabhängigkeit kein Wert per se, sondern erleichtert
bestenfalls das Schreiben automatischer Parser oder Codegeneratoren.

> ... nur dass in C eben die Statements erst während der Kompilation
> feststehen. Was für die Bearbeitung von C-Code und für dessen Verständnis
> durch Humanoide nicht eben vorteilhaft ist.

Ja, aber C ist halt auch extrem schlecht konzipiert. Bei anderen Sprachen
gibt es diesen Präprozessor-Unfug nicht: Nicht umsonst wurde z.B. in
C++ hart daran nachgebessert, die selben Möglichkeiten (und Optimierungen!)
ohne diesen Quatsch erreichen zu können. Zwar *könnte* man in C++ ein
Programm noch genauso verhunzen, aber man *muss* es nicht mehr, und alle
größeren und gut durchorganisierten Projekte vermeiden es.

>> Jede Anweisung eines C-Program kann an jede andere Position verschoben
>> werden ohne daß sich an der grammatischen Korrektheit des Programmes
>> dadurch etwas ändern würde.
>
> So?
>
> x = 1;
> if (foo)
> y++;
> else
> y--;

Neben dem Präprozessor ist die Möglichkeit von non-compound-Statements
das zweite große Verbrechen der C-Syntax. (In den meisten großen Porjekten
wird das ebenfalls vermieden - der Linux-Kernel macht hier eine
unrühmliche Ausnahme).
Diese werden allerdings üblicherweise auch nicht als "Block" bezeichnet,
wobei es natürlich formal nur eine Geschmacksfrage ist, wie man die Syntax
hier in eine abstrakte Form gießt (die von K&R getrofffene
Syntaxbeschreibung in EBNR ist ja nicht die einzige Möglichkeit - praktisch
kein moderner Compiler benutzt das mehr).
Wenn man solche non-compound-Statements (und leere Statements) ebenfalls
als Block bezeichnen will, wird natürlich *auch* die Block-Syntax von C
kontextsensitiv.

Rainer Weikusat

unread,

May 10, 2021, 10:26:46 AM5/10/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:
>>> So what? In Python ist die Formatierung Teil der logischen Struktur, und
>>> das hat den Vorteil, dass man die logische Struktur visuell erfassen
>>> kann, was in C o.ä. nicht der Fall ist.
>>
>> ... und es hat außerdem den Effekt --- warum kommt es mir nur so vor, als
>> hätte ich das schon mal geschrieben --- das Python nicht wirklich eine
>> blockstrukturierte Sprache ist, weil Codeblöcke auf unteren
>> Hierarchiebenen von dem Code in oberen Hierarchieebenen abhängig sind.
>
> Das hattest Du geschrieben. Und ich hatte darauf entgegnet, dass man die
> Codezeilen
>
> ----------- 1 ------------------
> a = 1
> b = 2
> ----------- 1 ------------------
>
> auffassen kann als den Codeblock
>
> ----------- 2 ------------------
> a = 1
> b = 2
> ----------- 2 ------------------
>
> und einer Einrückung von 4 Leerzeichen. Der Codeblock (also das, was mit
> "--- 2 ---" markiert ist, ist nicht abhängig von "Code in oberen
> Hierarchieebenen".
>
> Darauf hattest Du nichts mehr entgegnet.

Warum hätte ich mich hier wiederholen sollen? An meiner Aussage zu
diesem Thema hat sich nichts geändert.

>> Ein C-Programm (gilt auch für jede andere Sprache mit expliziten
>> Blockbegrenzern) besteht aus einer Folge von syntaktisch voneinander
>> unabhängigen Anweisungen. Manch dieser Anweisungen könne sogenannte
>> «compound statements», dh sie enthalten weitere Anweisungen. Die sind
>> aber wiederrum unabhänging voneinander und auch unabhängig von dem
>> Block, in dem sie enthalten sind:
>
> ... nur dass in C eben die Statements erst während der Kompilation
> feststehen. Was für die Bearbeitung von C-Code und für dessen Verständnis
> durch Humanoide nicht eben vorteilhaft ist.

Aus historischen Gründen beeinhaltet «C» eine Präprozessor, der
innerhalb gewisser Grenzen Textsubstitionen am Quellcode vornehmen
kann, bevor der Compiler ihn zu Gesicht bekommt. Das ist aber für eine
Betrachtung der Sprache irrelevant.

>
>> Jede Anweisung eines C-Program kann an jede andere Position verschoben
>> werden ohne daß sich an der grammatischen Korrektheit des Programmes
>> dadurch etwas ändern würde.
>
> So?
>
> x = 1;
> if (foo)
> y++;
> else
> y--;
>
> verschiebe mal bitte die erste Zeile vor das y++; und sage mir, ob das
> noch "grammatisch" korrekter C-Code ist.

Das sind zwei Anweisungen. Aber keine davon ist ein sogenanntes
Compound-Statement. Also kann man nicht eine legal in die andere hinein
bewegen, es geht nur

x = 1;
if (foo)
y++;
else
y--;

oder

if (foo)
y++;
else
y--;

x = 1;

Оlе Ѕtrеісhеr

unread,

May 10, 2021, 10:59:01 AM5/10/21

to

Meine Aussage:

"Der Codeblock (...), ist nicht abhängig von "Code in oberen
Hierarchieebenen".

widerlegt (mit ihrer Herleitung) deine Aussage:

"... weil Codeblöcke auf unteren Hierarchiebenen von dem Code in oberen
Hierarchieebenen abhängig sind."

Da kannst Du natürlich einfach mit den Schultern zucken und sagen
"... hat sich nichts geändert". Eine Diskussion ist das aber nicht.

>>> Ein C-Programm (gilt auch für jede andere Sprache mit expliziten
>>> Blockbegrenzern) besteht aus einer Folge von syntaktisch voneinander
>>> unabhängigen Anweisungen. Manch dieser Anweisungen könne sogenannte
>>> «compound statements», dh sie enthalten weitere Anweisungen. Die sind
>>> aber wiederrum unabhänging voneinander und auch unabhängig von dem
>>> Block, in dem sie enthalten sind:
>>
>> ... nur dass in C eben die Statements erst während der Kompilation
>> feststehen. Was für die Bearbeitung von C-Code und für dessen Verständnis
>> durch Humanoide nicht eben vorteilhaft ist.
>
> Aus historischen Gründen beeinhaltet «C» eine Präprozessor, der
> innerhalb gewisser Grenzen Textsubstitionen am Quellcode vornehmen
> kann, bevor der Compiler ihn zu Gesicht bekommt. Das ist aber für eine
> Betrachtung der Sprache irrelevant.

Der Preprozessor ist Teil der Sprache, und damit kann man ihn nicht
einfach ausklammern. Der Mensch bearbeitet den Quelltext schließlich,
bevor der Preprozessor in verwurstet. Darum ist für die Frage, wie
übersichtlich eine Sprache ist, und wie einfach sie durch Menschen zu
erfassen und zu bearbeiten ist, der Preprozessor relevant.

>> x = 1;
>> if (foo)
>> y++;
>> else
>> y--;
>>
>> verschiebe mal bitte die erste Zeile vor das y++; und sage mir, ob das
>> noch "grammatisch" korrekter C-Code ist.
>
> Das sind zwei Anweisungen. Aber keine davon ist ein sogenanntes
> Compound-Statement.

Das war Deine Behauptung:

>>> Jede Anweisung eines C-Program kann an jede andere Position verschoben
>>> werden ohne daß sich an der grammatischen Korrektheit des Programmes
>>> dadurch etwas ändern würde.

Ich lese da nichts von "Compound Statements". Ich lese da was von
"Anweisungen". Und von "jede andere Position".

Und da es in C auch einzelne Anweisungen geben kann (wie im Beispiel des
if-statements), kann man auch nicht einfach Code veschieben und davon
ausgehen, dass die Programmstruktur erhalten bleibt.

Fallen gibt es in jeder Sprache, da ist C keinen Deut besser als
Python. Darum ist Dein Python-Ranting an dieser Stelle schlicht
unangemessen. Gerade die Strukturierung mittels Einrücken erweist sich
als recht unproblematisch und gut automatisierbar (genau das hast Du ja
bezweifelt).

Ole

Rainer Weikusat

unread,

May 10, 2021, 11:59:26 AM5/10/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Rainer Weikusat <rwei...@talktalk.net> writes:

>> Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:

[...]

>> Warum hätte ich mich hier wiederholen sollen? An meiner Aussage zu
>> diesem Thema hat sich nichts geändert.
>
> Meine Aussage:
>
> "Der Codeblock (...), ist nicht abhängig von "Code in oberen
> Hierarchieebenen".
>
> widerlegt (mit ihrer Herleitung) deine Aussage:
>
> "... weil Codeblöcke auf unteren Hierarchiebenen von dem Code in oberen
> Hierarchieebenen abhängig sind."
>
> Da kannst Du natürlich einfach mit den Schultern zucken und sagen
> "... hat sich nichts geändert". Eine Diskussion ist das aber nicht.

Zu dieser steilen Theorie hatte ich mich bereits in Kontext des
Postings, indem sie ursprünglich verbreitet wurde geäußert und ich werde
das nicht wiederholen.

[...]

>>> x = 1;
>>> if (foo)
>>> y++;
>>> else
>>> y--;
>>>
>>> verschiebe mal bitte die erste Zeile vor das y++; und sage mir, ob das
>>> noch "grammatisch" korrekter C-Code ist.
>>
>> Das sind zwei Anweisungen. Aber keine davon ist ein sogenanntes
>> Compound-Statement.
>
> Das war Deine Behauptung:
>
>>>> Jede Anweisung eines C-Program kann an jede andere Position verschoben
>>>> werden ohne daß sich an der grammatischen Korrektheit des Programmes
>>>> dadurch etwas ändern würde.
>
> Ich lese da nichts von "Compound Statements". Ich lese da was von
> "Anweisungen". Und von "jede andere Position".

Ich auch. Allerdings kann man Anweisungen nicht in andere Anweisungen
hineinverschieben, außer dies anderen Anweisung sind zusammengesetzte
Anweisungen.

Die Annahme, ich hätte die (offensichtlich falsche) Aussage machen
wollen, dass man das könne, ist falsch.

Juergen Ilse

unread,

May 10, 2021, 3:07:43 PM5/10/21

to

Hallo,

Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:

> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>> Es ist einfach nur eine ueble Idee, Formatierung zu einem Teil der
>> Semantik zu machen. Warum ist diese einfache Erkenntnis so schnell
>> wieder verloren gegangen?
>
> Die Idee, Semantik und Formatierung unabhängig zu machen ist halt auch
> nicht das Gelbe vom Ei

Das sehe ich anders, denn das verbietet ja keineswegs eine uebersichtliche
Formatierung (auch wenn diese nicht erzwungen wird). Und wenn wir ehrlich
sind, muessen wir doch zugeben, dass auch in python fuer denjenigen der
das wieklich anstrebt, fast beliebig unlesbare Programme moeglich sind
(wie in fast jeder Programmiersprache).

> und erfordert Hilfsmittel, sehr geschulte Augen
> oder zusätzliche Richtlinien für die Erkennung der Fallen:
>
> while (foo());
> bar();

Unsinnige Formatierung, fuer den geuebten C-Programmierer trivial zu erkennen
(ein Tool wie "indent" wuerde diese unsinnige Formatierung auch automatisch
reparieren ... *ohne* die Gefahr, die Semantik zu veraendern).

> if (foo)
> if (bar)
> zoo();
> else
> zar();

unsinnige Formatierung, fuer den geuebten C-Programmierer leicht zu erkennen
und z.B. mit "indent" trivial "reparierbar ohne die Gefahr einer Semantik-
Aenderung.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

Оlе Ѕtrеісhеr

unread,

May 11, 2021, 2:30:34 AM5/11/21

to

Juergen Ilse <ne...@usenet-verwaltung.de> writes:
> Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:
>> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>>> Es ist einfach nur eine ueble Idee, Formatierung zu einem Teil der
>>> Semantik zu machen. Warum ist diese einfache Erkenntnis so schnell
>>> wieder verloren gegangen?
>>
>> Die Idee, Semantik und Formatierung unabhängig zu machen ist halt auch
>> nicht das Gelbe vom Ei
>
> Das sehe ich anders, denn das verbietet ja keineswegs eine uebersichtliche
> Formatierung (auch wenn diese nicht erzwungen wird).

Es ermöglicht einen vollkommen unsinnigen Wildwuchs, der einem gerade
dann auf die Füße fällt, wenn man in vielen Projekten involviert ist,
von denen jedes seine eigenen Vorstellungen von Formatierung hat.

Das hatte ich weiter vorn schon geschrieben: Ich betreue eine ganze
Reihe (>>100) Softwareprojekte in allen möglichen Sprachen. Von diesen
sind die Python-Projekte die angenehmsten, eben weil die einheitliche
Formatierung es leicht macht, sich hineinzudenken und ggfs. Probleme zu
finden und zu fixen.

> Und wenn wir ehrlich sind, muessen wir doch zugeben, dass auch in
> python fuer denjenigen der das wieklich anstrebt, fast beliebig
> unlesbare Programme moeglich sind (wie in fast jeder
> Programmiersprache).

In Python muss man unlesbaren Code anstreben, in anderen Sprachen ergibt
er sich von selbst :-)

>> und erfordert Hilfsmittel, sehr geschulte Augen
>> oder zusätzliche Richtlinien für die Erkennung der Fallen:
>>
>> while (foo());
>> bar();
>
> Unsinnige Formatierung, fuer den geuebten C-Programmierer trivial zu erkennen
> (ein Tool wie "indent" wuerde diese unsinnige Formatierung auch automatisch
> reparieren ... *ohne* die Gefahr, die Semantik zu veraendern).

Das hatte ich doch geschrieben: "erfordert Hilfsmittel, sehr geschulte
Augen oder zusätzliche Richtlinien".

Solche Stellen habe ich durchaus in professioneller, lange (>>10 Jahre)
gewarteter Software gefunden. Allen "geuebten C-Programmierern", die sich
den Code vorher angeschaut haben, zum Trotz.

Ole

Rainer Weikusat

unread,

May 11, 2021, 10:13:28 AM5/11/21

to

Оlе Ѕtrеісhеr <ole-use...@gmx.net> writes:
> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>> Оlе Ѕtrеісhеr <ole-use...@gmx.net> wrote:
>>> Juergen Ilse <ne...@usenet-verwaltung.de> writes:
>>>> Es ist einfach nur eine ueble Idee, Formatierung zu einem Teil der
>>>> Semantik zu machen. Warum ist diese einfache Erkenntnis so schnell
>>>> wieder verloren gegangen?
>>>
>>> Die Idee, Semantik und Formatierung unabhängig zu machen ist halt auch
>>> nicht das Gelbe vom Ei
>>
>> Das sehe ich anders, denn das verbietet ja keineswegs eine uebersichtliche
>> Formatierung (auch wenn diese nicht erzwungen wird).
>
> Es ermöglicht einen vollkommen unsinnigen Wildwuchs, der einem gerade
> dann auf die Füße fällt, wenn man in vielen Projekten involviert ist,
> von denen jedes seine eigenen Vorstellungen von Formatierung hat.

Als Mensch der mit genau diesem «Problem» seit 15 Jahren zu tun hat, muß
ich dem weiterhin widersprechen: Textformatierung, auch wild
durcheinandergehende (zB busybox) ist nie ein Problem beim Verstehen von
Code, daß ist immer der Code selber. Bestenfalls ist das ein Ärgernis,
weil man jedesmal, wenn man es mit einem anderen Code-Haufen zu tun
bekommt, daran denken muß, sich an einem anderen Satz von Konventionen
zu halten. Auch das könnte man vermutlich einfach lassen, aber es
erfreut das Auge, wenn Code nicht wie ein wildes Durcheinander aussieht.

Christian Hanné

unread,

May 12, 2021, 6:14:55 PM5/12/21

to

Am 05.05.2021 um 09:55 schrieb Оlе Ѕtrеісhеr:
> Rainer Weikusat <rwei...@talktalk.net> writes:

Au weia, ihr habt beide nen Dachschaden.

Marc Haber

unread,

May 13, 2021, 3:56:59 AM5/13/21

to

Christian Hanné <the....@gmail.com> wrote:
>Au weia, ihr habt beide nen Dachschaden.

Du kennst den Spruch mit dem Esel und bist noch nicht auf der Suche
nach einer saftigen Wiese?
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834