Seite 1 von 2

Verfasst: Montag 28. April 2008, 20:45
von EyDu
sea-live hat geschrieben:wo liegt der vorteil wenn ich dazu ein modul brauche
desweiteren
Es ist einfach gut getesteter Code aus der Standardbibliothek und warum sollte man etwas neu schreiben, was es schon gibt und genau dazu gedacht ist. Außerdem verringert es die eigenen Fehler. Und natülrich ist es auch viel lesbarer als ein lambda-Ausdruck.

Verfasst: Dienstag 29. April 2008, 07:51
von sea-live
Leonidas hat geschrieben:
sea-live hat geschrieben:wo liegt der vorteil wenn ich dazu ein modul brauche
Weil die Funktionalität von itemgetter dokumentiert ist und man nicht überlegen muss was irgendwelche Funktionen machen. Außerdem ist er womöglich auch schneller.
überzeugend und einleuchtend Danke für die Überaus lehrreiche Info

Verfasst: Dienstag 29. April 2008, 08:35
von birkenfeld
EyDu hat geschrieben:
sea-live hat geschrieben:wo liegt der vorteil wenn ich dazu ein modul brauche
desweiteren
Es ist einfach gut getesteter Code aus der Standardbibliothek und warum sollte man etwas neu schreiben, was es schon gibt und genau dazu gedacht ist. Außerdem verringert es die eigenen Fehler. Und natülrich ist es auch viel lesbarer als ein lambda-Ausdruck.
Das sehe ich anders. Ja, das Ding ist dazu gedacht. Aber ich kann nicht erkennen, was an ``lambda x: x["Date"]`` unlesbar ist, zumal man mit "itemgetter" auch nichts anfangen kann, wenn man nicht weiß was es genau tut.

Verfasst: Dienstag 29. April 2008, 11:01
von EyDu
Zugegeben, der Lambda-Ausdruck ist nicht schwierig zu lesen, aber man muss relativ genau hinschauen. "itemgetter" hingegen ist, zumindest für mich, sehr intuitiv. Und die Standard-Bibliothek nicht zu kennen, sollte ja wohl keine ausrede sein.

Verfasst: Dienstag 29. April 2008, 12:58
von sea-live
Mag sein das wir das hier jetzt breittreten
aber ich finde in keiner docu was zu itemgetter
weder bei google nioch bei pydocu und schon garnicht in wx docu

kann mal jemand diesen ominösen docu link hier einstellen

dazu ist das forum doch da es gibt massig was zu lamda

beides funktioniert wie man an den beispielen sieht

mich stört halt nur das lamda bereits ab 2.4 für diese dinge optimiert wurde
und in den standart namensraum übernommmen wurde
ich soll nun fürs bessere verständniss eine bibliotek nachladen was
beim compalieren dann zusätzlichen platz beansprucht.
Diskusion erwünscht minimalismuss gefordert beim Programmieren!

Verfasst: Dienstag 29. April 2008, 13:02
von EyDu
Hier geht es zur Doku von "operator.itemgetter".

Verfasst: Dienstag 29. April 2008, 14:05
von helduel
Moin,
sea-live hat geschrieben:mich stört halt nur das lamda bereits ab 2.4 für diese dinge optimiert wurde
die itemgetter-Funktion ist schneller als die lambda-Funktion.
ich soll nun fürs bessere verständniss eine bibliotek nachladen was
beim compalieren dann zusätzlichen platz beansprucht.
Gerade getestet: Die lambda-Variante ist kompiliert größer als die itemgetter-Variante:

Code: Alles auswählen

l = [[1,2,3,4]]
print filter(lambda x: x[2], l)
Größe: 271 Bytes.

Code: Alles auswählen

import operator
l = [[1,2,3,4]]
print filter(operator.itemgetter(2), l)
Größe: 224 Bytes.

Gruß,
Manuel

Verfasst: Dienstag 29. April 2008, 14:31
von Leonidas
sea-live hat geschrieben:mich stört halt nur das lamda bereits ab 2.4 für diese dinge optimiert wurde
und in den standart namensraum übernommmen wurde
Quatsch. Lambda ist schon seit fast immer da (mindestens seit 1.5.x), die Überlegung war sogar, es für Python 3.0 wegzulassen, da viele Anwendungsbereiche für lambdas durch andere Konstrukte übernommen worden sind, etwa ``filter()`` und ``map()`` durch List Comprehensions, Attribut und Indexzugriff durch Itemgetter und Attrgetter, etc.
sea-live hat geschrieben:Diskusion erwünscht minimalismuss gefordert beim Programmieren!
Ich habe letztens ein Programm geschrieben, in dem ich reihenweise Scheme Grundfunktionen nachgebaut habe, aber sonderlich gut war das Programm nicht. Ich würde lieber Funktionen der Stdlib verwenden, als sie einfach so nachzubauen.

Verfasst: Dienstag 29. April 2008, 14:52
von jens
sea-live hat geschrieben:kann mal jemand diesen ominösen docu link hier einstellen
Oben gibt es ja schon ein Link, in der neuen Doku sind allerdings auch Beispiele: [mod]operator#operator.itemgetter[/mod]

EDIT: btw. zum Thema Sortieren, gibt es auch diese Seite im Wiki: [wiki]Sortierungs-Tutorium[/wiki]

Verfasst: Dienstag 29. April 2008, 18:08
von sea-live
da sag ich mal DANKE

mit dem beitrag von Jens haben sich dann alle fragen erübrigt

wer suchet der findet dieser thread hats nun wirklich insich!

Verfasst: Dienstag 29. April 2008, 19:19
von Y0Gi
EyDu hat geschrieben:Außerdem würde man statt deinem Lambda-Ausdruck 'operator.itemgetter("Date")' verwenden.
Ich nicht. `itemgetter` sieht vielleicht sauberer aus, aber mich stört der zusätzliche Import sehr. Wenn `itemgetter` im Standard-Namespace *wäre*, würde ich es verwenden, aber so ist das Lambda-Konstrukt trotzdem handlicher - plus die Flexibilität, es später noch anzupassen, wenn man die Datenstruktur ändern sollte.

Leonidas hat geschrieben:Weil die Funktionalität von itemgetter dokumentiert ist und man nicht überlegen muss was irgendwelche Funktionen machen.
Und die von `lambda` nicht? Dann habe ich wohl 'ne andere Doku als du :p
Leonidas hat geschrieben:Außerdem ist er womöglich auch schneller.
Das ist soweit ich das sehe nur eine Mutmaßung.


sea-live:
In deinem Code-Beispiel ist die `main()`-Funktion reichlich witzlos, sofern `main()` nicht z.B. in der gängigen Bedingung `if __name__ == '__main__':` verpackt ist.

Verfasst: Dienstag 29. April 2008, 19:41
von EyDu
Wir diskutieren doch jetzt nicht schon eine Seite darüber, oder? Ich glaube beide Seiten können die Argumente der anderen nachvollziehen (und wissen ganz genau, dass sie selbst im Recht sind ;-) ) und letzendlich endet es in einer Geschmacksfrage.

Verfasst: Dienstag 29. April 2008, 22:45
von Y0Gi
Dann ist wohl Tatsache, dass es zwei Lösungen gibt, die beide eingeschränkt sind und sich entsprechend nicht durchsetzen wollen? Oder gibt es vielleicht einfach zufällig beide, weil `lambda` es einfach kann und `itemgetter` aus vermutlichen Gründen der Überladung existiert? Wird es das System/Python-Zen von Innen auffressen? ZOMG!

Verfasst: Mittwoch 30. April 2008, 07:12
von BlackJack
Vielleicht resultiert `itemgetter()` ja auch aus der Überlegung heraus, dass ``lambda`` abgeschafft werden sollte. Konnte ja keiner ahnen, das der BDFL da doch noch einlenkt. :-)

Verfasst: Mittwoch 30. April 2008, 10:30
von Leonidas
Y0Gi hat geschrieben:
Leonidas hat geschrieben:Weil die Funktionalität von itemgetter dokumentiert ist und man nicht überlegen muss was irgendwelche Funktionen machen.
Und die von `lambda` nicht? Dann habe ich wohl 'ne andere Doku als du :p
Du Funktionalität von ``lambda`` schon, die von diesem speziellen Lambda nicht.
Y0Gi hat geschrieben:
Leonidas hat geschrieben:Außerdem ist er womöglich auch schneller.
Das ist soweit ich das sehe nur eine Mutmaßung.
``itemgetter()`` ist immerhin in C implementiert, das ``lambda`` ist Python-Code, daher ist die Mutmaßung gar nicht mal so abwegig.

Über den Import zu Argumentieren finde ich eher langweilig. Ich importiere in meinen Programmen was ich will, da muss ich mir im Fall der Stdlib keine Sorgen machen ob es installiert ist oder nicht.

Verfasst: Mittwoch 30. April 2008, 11:29
von Y0Gi
Leonidas hat geschrieben:Du Funktionalität von ``lambda`` schon, die von diesem speziellen Lambda nicht.
Dann müsste ich dir im Falle von `lambda x: x[0]` unterstellen, dass du Lambdas nicht verstanden hast. Ein noch einfacheres Beispiel gibt es wohl kaum.

Leonidas hat geschrieben:Über den Import zu Argumentieren finde ich eher langweilig. Ich importiere in meinen Programmen was ich will, da muss ich mir im Fall der Stdlib keine Sorgen machen ob es installiert ist oder nicht.
Es ging mir nicht darum, ob ich einen Import vertreten kann. Bei etwas aus der Stdlib geht das auf jeden Fall. Vielmehr stört mich, dass ich für ein so einfaches Konstrukt überhaupt etwas importieren muss*, wodurch mein gedanklicher Fluss beim Programmieren zumindest kurzzeitig unterbrochen wird. Dabei ist es ein gerne und zu Recht angeführtes Argument, dass man in Python sehr direkt und ohne Umschweife, etwa im Vergleich zu C, ein Problem bzw. dessen Lösung umsetzen kann.

*) Interessanterweise könnte man das auch vom `with`-Statement behaupten. Das allerdings ist IMHO nicht nur vielseitiger, sondern wird in kurzer Zeit auch ohne Import funktionieren.

Verfasst: Mittwoch 30. April 2008, 12:03
von helduel
Y0Gi hat geschrieben:Es ging mir nicht darum, ob ich einen Import vertreten kann. Bei etwas aus der Stdlib geht das auf jeden Fall. Vielmehr stört mich, dass ich für ein so einfaches Konstrukt überhaupt etwas importieren muss*, wodurch mein gedanklicher Fluss beim Programmieren zumindest kurzzeitig unterbrochen wird. Dabei ist es ein gerne und zu Recht angeführtes Argument, dass man in Python sehr direkt und ohne Umschweife, etwa im Vergleich zu C, ein Problem bzw. dessen Lösung umsetzen kann.
Man könnte auch alle Funktionen im operator-Modul als "einfach" ansehen und sich fragen, warum man die erst importieren muss. Aber das würde den Namensraum ziemlich zumüllen.

Ich würde auch nicht sagen, dass eine Funktion, die ein callable zurück gibt, das aus einer ihm übergebenen Liste den Wert eines vorher definierten Index zurückliefert, wirklich als "einfach" bezeichnet werden kann, selbst wenn das mit lambda ein Einzeiler ist.

Würde es lambda nicht geben, dann müsstest du extra eine Funktion schreiben (lambda ist ja nichts anderes). Aber lambda bleibt uns erhalten und man hat weiter die Möglichkeit 'sehr direkt und ohne Umschweife ein Problem, bzw. dessen Lösung umzusetzen'. Man muss das operator-Modul ja nicht verwenden. Will man aber Geschwindigkeit, dann ist lambda oft/meistens/immer die schlechtere Wahl. Und warum sollte ich eine Funktion (selbst einen Einzeiler) neu schreiben, wenn es die schon (besser) gibt? Dann mach ich halt den doofen import.

Verfasst: Mittwoch 30. April 2008, 12:29
von Y0Gi
Wenn der doofe Import nicht wäre, wäre das auch gar kein Thema. (Beweisbare) Geschwindigkeit ist dagegen ein handfestes Argument. Ich werde in Zukunft den `operator`-Ansatz testen.

Nur so eine Idee: Gibt es nicht eine entsprechende Methode `__foo__`, die `itemgetter()` entspricht und die man zur Vermeidung des Imports von einem "rumliegenden" Typ oder Objekt abgreifen kann? So wie man z.B. `map(', '.join, names)` nutzen kann? Okay, das würde fragwürdiger Stil werden, aber man spart den Import ;)

Verfasst: Mittwoch 30. April 2008, 13:05
von EyDu
In Haskell ist der von dir sogenannte fragwürdige Stil an jeder Ecke anzutreffen. Nennt "point-free programming". Im bekanntesten Haskell-Tutorial wird außerdem darauf verwiesen, dass man es doch bitte nicht mit "pointless programming" verwechseln soll :D

Verfasst: Mittwoch 30. April 2008, 13:59
von Leonidas
Y0Gi hat geschrieben:Nur so eine Idee: Gibt es nicht eine entsprechende Methode `__foo__`, die `itemgetter()` entspricht und die man zur Vermeidung des Imports von einem "rumliegenden" Typ oder Objekt abgreifen kann?
Ohne Callable ist das ja auch nichts kompliziertes:

Code: Alles auswählen

>>> import operator
>>> l = range(5)
>>> operator.itemgetter(2)
<operator.itemgetter object at 0x81a8dcc>
>>> i2 = operator.itemgetter(2)
>>> i2(l)
2
>>> l.__getitem__(2)
2
``attrgetter`` ist ja auch nur ein ``getattr()`` in einem Callable.

Closures sind schon toll, ``itemgetter`` funktioniert etwa so:

Code: Alles auswählen

>>> def yogi_itemgetter(index):
...     def actual_getter(obj):
...         return obj[index]
...     return actual_getter
... 
>>> yi2 = yogi_itemgetter(2)
>>> yi2(l)
2
Et voila, schon sind wir einen Import los. Alternativ kann man es einmal importieren und es dann in die __builtins__ injecten, aber wenn ich sehe das jemand die Builtins verändert bin ich in Steinigungsstimmung ;)