Umgedrehtes if

[maxip]

Hi,

ich wurde gerne statt

Code: Alles auswählen

if debug: print x

gerne sowas wie

Code: Alles auswählen

print x if debug

schreiben. Ich bin mir nicht sicher, aber ich glaube ich hab das mal in Python gesehen, wie ist da die genau Syntax, weil so wie oben funktioniert es nicht...

[Hyperion]

Da stellt sich mir nur die Frage: Wozu? Ist doch semantisch exakt identisch und wäre nur eine Variation der vorhandenen Schreibweise.

Ich habe so etwas iirc noch nicht gesehen - aber die Gurus hier werden sicherlich etwas dazu sagen können

[Daniela]

Welchen Sinn soll denn dieses "umgedrehte" if denn haben.

Ich kann da im Moment nicht wirklich den Sinn erkennen.

Die normale if-Anweisung ist doch ansich logisch. erst wenn eine Bedingung eingetroffen ist, soll etwas gemacht werden.

Wenn erst ein Ereignis eintretten soll, und dann eine Bedingungsprüfung stattfinden soll, fällt mir spontan nur eine fussgesteuerte do-while-Schleife (http://de.wikipedia.org/wiki/Do-while-Schleife) ein. Jedenfalls für Java.
Ich weiß nicht, vielleicht gibt es so was ähnliches auch für Python?!

[audax]

Es gibt nur den unären Operator, also:

Code: Alles auswählen

print "foo" if False else "bar"
# "bar"

[numerix]

Du hast vermutlich so etwas gesehen:

Code: Alles auswählen

s = "gerade" if a%2 == 0 else "ungerade"

[numerix]

Welchen Sinn soll denn dieses "umgedrehte" if denn haben.

Ich kann da im Moment nicht wirklich den Sinn erkennen.

Der "Sinn" ist, dass man in solchen Fällen, wo es um eine alternative Zuweisung geht, den Code knapper - und je nach Geschmack - übersichtlicher halten kann.

[Daniela]

Welchen Sinn soll denn dieses "umgedrehte" if denn haben.

Ich kann da im Moment nicht wirklich den Sinn erkennen.

Der "Sinn" ist, dass man in solchen Fällen, wo es um eine alternative Zuweisung geht, den Code knapper - und je nach Geschmack - übersichtlicher halten kann.

Aha, wenn das so ist.

Vielleicht am Anfang ein bissl verwirrend, wenn man jetzt nicht so an diese schreibweise gewöhnt ist.

Letztlich sowieso eine Geschmacksfrage.

[audax]

Welchen Sinn soll denn dieses "umgedrehte" if denn haben.

Ich kann da im Moment nicht wirklich den Sinn erkennen.

Die normale if-Anweisung ist doch ansich logisch. erst wenn eine Bedingung eingetroffen ist, soll etwas gemacht werden.

Wenn erst ein Ereignis eintretten soll, und dann eine Bedingungsprüfung stattfinden soll, fällt mir spontan nur eine fussgesteuerte do-while-Schleife (http://de.wikipedia.org/wiki/Do-while-Schleife) ein. Jedenfalls für Java.
Ich weiß nicht, vielleicht gibt es so was ähnliches auch für Python?!

Ja.

Code: Alles auswählen

while True:
    do_stuff()
    if foo():
        break

[Leonidas]

Code: Alles auswählen

sys.stdout.write('a\n' if True else '')

Die Bedingung ist dann jeweils zum Testen anzupassen.

[numerix]

Und mit print geht es tatsächlich auch:

Code: Alles auswählen

print ("ungerade" if a%2 else "gerade")

[nummer9]

Wenn du knappen Code schreiben möchtest, geht statt

Code: Alles auswählen

if foo==bar:
    print "haha"
print "hi"
print "ho"

auch

Code: Alles auswählen

if foo==bar: print "haha"
print "hi"; print "ho"

Ist aber verpöhnt und eigentlich immer unnötig und unübersichtlich.

[sechsrad]

Die normale if-Anweisung ist doch ansich logisch. erst wenn eine Bedingung eingetroffen ist, soll etwas gemacht werden.

if wahr dann print "wahr"
was ist daran logisch, verstehe ich nicht.

print "wahr" wenn if wahr !
was ist an dieser fragestellung unlogisch?


oder in forth :

34 45 +

ist mathematisch verständlicher als 34 + 45 ...

mfg

[Karl]

Die normale if-Anweisung ist doch ansich logisch. erst wenn eine Bedingung eingetroffen ist, soll etwas gemacht werden.

was ist daran logisch, verstehe ich nicht.

print "wahr" wenn bedingung wahr ist !

was ist an dieser fragestellung falsch?


oder in forth :

34 45 +

ist mathematisch verständlicher als 34 + 45 ...

mfg

Welche Fragestellung? Eher ein Ausdruck :p
Und was ist an 34 45 + "mathematisch verständlicher"? als an 45 + 45?
Erklär mir das mal bitte.
Aber zum eigentlichem Thema:
Ist logisch völlig gleich, wie rum ich das if drehe.
Hauptsache es besteht der Zusammenhang zwischen dem If und dem
Then, bzw dem Do ... if

[Leonidas]

In Lisp:

Code: Alles auswählen

(+ 34 45)

Ich denke sechsrad wollte ausdrücken dass die RPN keine zusätzlichen Klammern braucht um Präzedenzen richtig aufzulösen.

Was es hier mit dem Thema zu tun hat - keine Ahnung.

[sechsrad]

Und was ist an 34 45 + "mathematisch verständlicher"? als an 45 + 45?

ich kann doch erst 2 zahlen addieren , wenn diese vorhanden sind.

ist doch unlogisch wenn ich eine zahl habe und die schon mit einem zeichen addiere(+).

schau dir mal den asm-code an, dort werden erst die beiden zahlen in empfang genommen und dann addiert, vorher geht es nicht.


vom assembler verlangen wir die verständlichkeit aber schreiben tun wir chaotisch und meinem , das es logisch ist.

jetzt wird aber vom thema abgegangen....

mfg

[str1442]

Das ist auch ganz nützlich und übersichtlicher bei Verwendung in längeren Zeilen, zb sowas mit ner for schleife:

Code: Alles auswählen

somefunction("blabla bla bla %s %s" % (",".join(obj.var for obj in someobjlist, y)))

Und unrecht hat sechsrad mit der 34 45 + Sache nicht, eigentlich ist es schon logischer erst die "festen" Werte zu nehmen und dann erst einen Operator drauf anzuwenden.

[Leonidas]

Und unrecht hat sechsrad mit der 34 45 + Sache nicht, eigentlich ist es schon logischer erst die "festen" Werte zu nehmen und dann erst einen Operator drauf anzuwenden.

Seine Argumentation beist sich aber in den Schwanz:

if wahr dann print "wahr"
was ist daran logisch, verstehe ich nicht.

print "wahr" wenn if wahr !
was ist an dieser fragestellung unlogisch?

Vor allem wenn er dann mit Assembler argumentiert, wo man ja auch erst einen bedingten Sprung hat und dann erst den Code und nicht erst Code dann die Bedingung unter der er ausgeführt werden soll.

[EyDu]

"Mache ... wenn ..."-Konstrukte sind in normaler Sprache schon recht ungünstig, warum sollte sie man dann bei Programmiersprachen einführen. So ein typischer unglücklicher Satzbau ist "Langer Satz..., viele Nebensätze, ... nicht." Der eigentliche Sinn des Satzez ergibt sich erst ganz zum Ende. Selbiges würde sich ergeben, wenn man das "wenn" ans Ende stellt.

Den Operator hinter die Operanden zu stellen ist einfach nur menschenverachtend Wie soll man das denn noch lesen? Und nur weil ein Rechner erst die Operanden laden muss um dann die Operation auszuführen ist kein Grund es so zu schreiben, dass die Übersicht verloren geht. Infixnotation ist eben für den Menschan am lesbarsten.

Vielleicht tut eine Priese Haskell mal ganz gut, dort kann man Operationen auch partiell ausführen. Da sind die Operationen auch vor den Operanden da.

[Hyperion]

Den Operator hinter die Operanden zu stellen ist einfach nur menschenverachtend

Oha ... mach doch mal ne Eingabe bei der UN-Menschenrechtskommission SCNR

[epsilon]

@ maxip:

In Perl geht das (vielleicht hast du es da gesehen?)

print 'foo!' if $Wort eq 'foo'; # eq für equal

statt

if( $Wort eq 'foo' ){
print 'foo!'
}

Was ich auch gut finde, was es aber scheinbar nicht in Python gibt, ist 'unless': print 'foo!' unless $Wort ne 'foo'; # nq für not equal

Ich verwend' das manchmal um die hässlichen Klammern weglassen zu können.
Das ganze ist allerdings schlechter lesbar, wie EyDu bereits geschrieben hat