Lambda/If-Anweisungen

[__deets__]

Na dann muss die Bedingung noch anders lauten. Mit einem if/ else ternären Ausdruck entweder den Lexikographischen vergleich zurückgeben wenn Länge gleich, sonst eben nach Länge.

So wie bisher ist tatsächlich falsch ist mir nach nochmaligem betrachten klar geworden.

Und der Rest des Codes ist von deinem Prof? Na herzlichen Glückwunsch.

[snafu]

Ich würde da mit Tupeln arbeiten. In Verbindung mit sorted() würde ich das so machen:

Code: Alles auswählen

liste = ['xx', 'aaa', 'b', 'cc']
sorted(liste, key=lambda x: (len(x), x))

Und da du ja das kleinere Element zurückliefern willst:

Code: Alles auswählen

lambda a, b: a if (len(a), a) < (len(b), b) else b

Python guckt sich hierbei zunächst die jeweils ersten Elemente der Tupel an. Sind diese unterschiedlich dann beruht das Ergebnis auf dem Vergleich dieser Elemente. Sind sie hingegen gleich, dann wird der Vergleich der jeweils zweiten Elemente das Ergebnis sein.

Ansonsten halt:

Code: Alles auswählen

lambda a, b: a if (len(a) < len(b) or a < b) else b

[Sirius3]

@d_rose: Eingerückt wird in Python immer mit 4 Leerzeichen pro Ebene, nicht 8 und auch nicht 11. Variablen werden per Konvention klein geschrieben. Einbuchstabige Variablennamen sind schlecht; Variablennamen mit sinnlosen Nummern zu erweitern auch.

Und falls es Dir nicht klar war, auch normale Funktionen mit def kann man als Parameter an andere Funktionen übergeben, es muß kein Lambda sein.

Zu `sortiere`: Funktionen die ein übergebenes Objekt verändern, sollten das klar in ihrem Doc-String benennen. Das erwartete Verhalten sollte sein, dass alles, was man einer Funktion übergibt, sich nicht verändert. Bei Ausnahmen (wie z.B. list.sort) ist Konvention, dass diese Funktionen keinen Rückgabewert haben, um nochmal deutlich zu machen, dass das Ergebnis die übergebene Liste ist. Das `range` startet einen Index zu früh, denn der erste Vergleich ist der trenner mit sich selbst.

[d_rose]

@d_rose: Eingerückt wird in Python immer mit 4 Leerzeichen pro Ebene, nicht 8 und auch nicht 11. Variablen werden per Konvention klein geschrieben. Einbuchstabige Variablennamen sind schlecht; Variablennamen mit sinnlosen Nummern zu erweitern auch.

Und falls es Dir nicht klar war, auch normale Funktionen mit def kann man als Parameter an andere Funktionen übergeben, es muß kein Lambda sein.

Zu `sortiere`: Funktionen die ein übergebenes Objekt verändern, sollten das klar in ihrem Doc-String benennen. Das erwartete Verhalten sollte sein, dass alles, was man einer Funktion übergibt, sich nicht verändert. Bei Ausnahmen (wie z.B. list.sort) ist Konvention, dass diese Funktionen keinen Rückgabewert haben, um nochmal deutlich zu machen, dass das Ergebnis die übergebene Liste ist. Das `range` startet einen Index zu früh, denn der erste Vergleich ist der trenner mit sich selbst.

Das man def-Funktionen weitergeben kann als parameter ist mir klar ,ändert aber nichts daran das es ein Lambda-Ausdruck sein soll.
Am code vom Prof will ich auch nichts verändern, außer jemand kann mir genau sagen das er falsch ist.
Und wie die Variablen in erster Linie heißen ist mir auch egal, das kann man ja alles im Nachhinein nochmal verschönern.
So wie der code da steht, abgesehen vom Lambda-ausdruck steht er in der Handreichung.
Aber danke für die kleine Exkursion auch wenn es sich wie ein Bashing liest anstatt einer netten Hilfestellung.

[__blackjack__]

Wie Variablen heissen sollte Dir nicht egal sein, das ist auch nichts was man im Nachhinein ”verschönern” kann, weil gute Namen keine ”Dekoration” sind, sondern *wichtig*.

Das hilft sowohl beim Programmieren, als auch bei der Fehlersuche, und natürlich erst recht wenn andere den Code lesen und verstehen müssen. Wenn einem für ein Wert beispielsweise kein sinnvoller Name einfällt, dann hat man oft das Problem noch nicht ganz verstanden (oder die eigene Lösung), oder man hat bei zusammengesetzten Werten (Tupel, Klassen, …) Sachen zusammengeworfen, die sehr wahrscheinlich nicht zusammen gehören. Bei Funktionen oder Methoden weisst es oft darauf hin, das die Funktion/Methode zu viel macht oder der Code nicht sinnvoll auf die Funktionen/Methoden aufgeteilt wurde. Gleiches gilt für Klassen.

[d_rose]

Wie Variablen heissen sollte Dir nicht egal sein, das ist auch nichts was man im Nachhinein ”verschönern” kann, weil gute Namen keine ”Dekoration” sind, sondern *wichtig*.

Das hilft sowohl beim Programmieren, als auch bei der Fehlersuche, und natürlich erst recht wenn andere den Code lesen und verstehen müssen. Wenn einem für ein Wert beispielsweise kein sinnvoller Name einfällt, dann hat man oft das Problem noch nicht ganz verstanden (oder die eigene Lösung), oder man hat bei zusammengesetzten Werten (Tupel, Klassen, …) Sachen zusammengeworfen, die sehr wahrscheinlich nicht zusammen gehören. Bei Funktionen oder Methoden weisst es oft darauf hin, das die Funktion/Methode zu viel macht oder der Code nicht sinnvoll auf die Funktionen/Methoden aufgeteilt wurde. Gleiches gilt für Klassen.

Gebe ich dir vollkommen recht. Versuche es in Zukunft besser zu machen.