Das deutsche Python-Forum

Warum haben Tupel keine .index(x)-Methode

?

Diese Frage stelle ich aus reiner Neugier, da meiner Meinung nach eine .index(x)-Methode für Tupel so naheliegend ist. Natürlich habe ich kein echtes Problem damit, da ich ja zum Beispiel

Code: Alles auswählen

Tupel = (2,3,5,7,11,13,17,19)
ind = list(Tupel).index(7)

schreiben kann, und vieleicht sogar eine eigene Tupel-Klasse mit einer zusätzlichen Methode schreiben kann. Aber ist so etwas performant?

Man könnte es ganz einfach machen oO

Code: Alles auswählen

class MyTuple(tuple):
    def index(self, value):
        for j, i in enumerate(self):
            if i == value:
                return j

Aber warum nicht gleich listen nehmen?

Interessant zum Thema:
http://mail.python.org/pipermail/python ... 35951.html

Goswin hat geschrieben:Warum haben Tupel keine .index(x)-Methode?

Hallo Goswin!

Tuppel sind ressourcenschonender als Listen. Dafür muss man aber auch auf ein paar Dinge verzichten.

Und wenn ich mehr brauche als mir ein Tuppel zur Verfügung stellen kann, steige ich auf eine Liste um.

mfg
Gerold

Im von CM zitierten Parallelforum hei3t es unter anderem:

I use tuples
when I already know what goes into them and in what order.
index() and count() are totally useless
when you use tuples (or, indeed, any sequence) in this manner.

Im Gegensatz zu meinem Programm wei3 ich als Mensch natürlich, an welcher Stelle des Tupels mein x liegt, und könnte versuchen, es auch abzuspeichern und im Algoritmus mitzuführen. Aber das geht auch nur, wenn das x als Key zu gebrauchen ist, zum vorherigen Beispiel:

Code: Alles auswählen

Tupel = (2,3,5,7,11,13,17,19)
wo_in_Tupel = {2:0, 3:1, 5:2, 7:3, 11:4, 13:5, 17:6, 19:7}
ind = wo_in_Tupel[7]

Ich hoffe einmal, dass das trotz des zusätzlichen Dictionarys effizienter ist als eine Listenabfrage. Oder?

Goswin hat geschrieben:Ich hoffe einmal, dass das trotz des zusätzlichen Dictionarys effizienter ist als eine Listenabfrage. Oder?

Wohl kaum.

Hast du eigentlich was gegen Pythoncode-Tags?

OK CM, ich drücke mich mal besser aus:
Ich hoffe, dass trotz eines zusätzlichen Dictionary-Aufbaus 100000 Dictionary-Abfragen effizienter sind als 100000 Listenabfragen. Und falls es weniger Abfragen sein sollten, hoffe ich, dass es zumindest nicht viel langsamer ist.

Danke für den Hinweis, das es Textobjekte (?) gibt, die Tags hei3en, und mit welchen man das Problem unter Umständen auch angehen kann; ich habe sie soeben in meinem Pythonbuch entdeckt und werde sie mir bei Gelegenheit anschauen. Wie sollte ich etwas gegen eine Sache haben, von der ich nicht einmal gewu3t habe, das sie existiert! Ich komme halt aus einem gaaanz primitiven, nicht objektorientierten, und sehr lückenbehafteten C-Hintergrund.

Goswin hat geschrieben:Danke für den Hinweis, das es Textobjekte (?) gibt, die Tags hei3en, und mit welchen man das Problem unter Umständen auch angehen kann; ich habe sie soeben in meinem Pythonbuch entdeckt und werde sie mir bei Gelegenheit anschauen. Wie sollte ich etwas gegen eine Sache haben, von der ich nicht einmal gewu3t habe, das sie existiert! Ich komme halt aus einem gaaanz primitiven, nicht objektorientierten, und sehr lückenbehafteten C-Hintergrund.

Uh? Was hat das den mit Python als Programmiersprache, bzw mit deinem Programmiersprachen-Hintergrund zu tun?

Es geht darum, Code im Forum farblich aus zu zeichnen. Dafür brauch man kein Buch, dafür muss man sich einfach mal nur die Knöpfe anschauen, die beim Posten so über dem Textfeld sind. Die haben nämlich auch einen Sinn, weißt du...

@Goswin
Mit lieben Grüßen von Lunar.
Scheinbar meint er es nicht so wie er es schreibt.
Es gibt Python-Neulinge, die nicht soviel wie er von Python und diesem Forum wissen. Damit die es trotzdem schnell begreifen, hat er halt eine sehr direkt Ausdrucksweise.
Mfg
HWK

HWK hat geschrieben:Es gibt Python-Neulinge, die nicht soviel wie er von Python und diesem Forum wissen.

Aber manchmal erstaunt es mich dann doch, dass die Leute nicht auf die Idee kommen, zu gucken was passiert wenn man das Ding mit der Aufschrift "Python" drücken.

Ich fasse alles an was ich nicht verstehe.

PS: Immer diese C Programmiere mit ihrer preformance

HWK hat geschrieben:Mit lieben Grüßen von Lunar.
Scheinbar meint er es nicht so wie er es schreibt.
Es gibt Python-Neulinge, die nicht soviel wie er von Python und diesem Forum wissen. Damit die es trotzdem schnell begreifen, hat er halt eine sehr direkt Ausdrucksweise.

Endlich mal jemand, der mich versteht

gerold hat geschrieben: Tuppel sind ressourcenschonender als Listen. Dafür muss man aber auch auf ein paar Dinge verzichten.

Was jetzt das eine (weniger Speicherbedarf -- übrigens auch nur, wenn die Liste nicht zuviel overallocated hat, was bei kleinen Listen kaum vorkommt) mit dem anderen (fehlende Methode) zu tun hat, kann ich allerdings nicht erkennen.

MaW: wenn Tupel als "ressourcenschonende Listen" gedacht wären, gäbe es keinen Grund, ihnen kein index() zu geben.

birkenfeld hat geschrieben:MaW: wenn Tupel als "ressourcenschonende Listen" gedacht wären, gäbe es keinen Grund, ihnen kein index() zu geben.

Hallo birkenfeld!

Ich habe nicht die Zeit und nicht die Lust, mir den Quellcode von Python durchzusehen. Ich gehe nur von meiner ärmlichen Hauslogik aus. --> Ein leichter Rucksack trägt sich einfacher als ein schwerer Rucksack.

Und der einzige Existenzgrund für ein Tuppel, ist in meinen Augen der, dass man damit weniger Last mitschleppt und dadurch das Programm schneller, kleiner und besser wird. So habe ich das zumindest immer zwischen den Zeilen herausgelesen.

lg
Gerold

gerold hat geschrieben:
birkenfeld hat geschrieben:MaW: wenn Tupel als "ressourcenschonende Listen" gedacht wären, gäbe es keinen Grund, ihnen kein index() zu geben.
Hallo birkenfeld!

Ich habe nicht die Zeit und nicht die Lust, mir den Quellcode von Python durchzusehen. Ich gehe nur von meiner ärmlichen Hauslogik aus. --> Ein leichter Rucksack trägt sich einfacher als ein schwerer Rucksack.

Und der einzige Existenzgrund für ein Tuppel, ist in meinen Augen der, dass man damit weniger Last mitschleppt und dadurch das Programm schneller, kleiner und besser wird. So habe ich das zumindest immer zwischen den Zeilen herausgelesen.

Das ist leider nicht so. Zwar haben, wie gesagt, manche Listen einen höheren Speicherverbrauch als ein entsprechendes Tupel, weil sie mehr Speicher allozieren als nötig, um viele realloc()s zu sparen, aber schneller oder besser wird ein Programm dadurch nicht.

@Birkenfeld: Kannst du denn mal kurz und knapp (mit C-Kenntnissen als Voraussetzung) erlaeutern, wie sich Tupel und Lists noch so im Speicher unterscheiden, außer eben das die Liste veraenderbar ist und das Tupel nicht?

Also ich stelle mir das ungefaehr so vor:
Ein Tuple entsteht, indem einfach die zusammenaddierte Bytegroesse des Tuple-Inhalts alloziiert und das entstandene Objekt nicht mehr angefasst wird. Eine Liste brauch unmengen an Zusatzfunktionen. Sie muss sich staendig neualloziieren und ihren Inhalt veraendern koennen. Das muss ein Tuple nicht.

Aber aendert das etwas an der Geschwindigkeit? Schließlich ist der Abruf eines einzelnen Objektes innerhalb eines Tuples oder einer Liste doch das gleiche. Mache ich also mit einer Liste das gleiche wie mit einem Tuple, sollte es doch speicher- und geschwindigkeitstechnisch keinen Unterschied machen (außer eben bei der erwaehnten Sache mit der Ueberalloziierung, bei großen Listen)... liege ich da richtig?

@Goswin: Ich glaube nicht das es effizienter ist, ein zusaetzliches Dictionary zu bemuehen. Ein einfaches durchlaufen durch eine Liste um ein Objekt darin zu finden, sollte recht schnell gehen... auch bei hunderttausenden Objekten.
Das Dictionary hingegen wuerde riesengroß werden. Ein unnoetiger Klotz den ein bisschen mehr Prozessorlast ohne weiteres ueberfluessig macht.

Gruß
NKoehring

nkoehring hat geschrieben: Ein einfaches durchlaufen durch eine Liste um ein Objekt darin zu finden, sollte recht schnell gehen... auch bei hunderttausenden Objekten.
Das Dictionary hingegen wuerde riesengroß werden. Ein unnoetiger Klotz den ein bisschen mehr Prozessorlast ohne weiteres ueberfluessig macht.

Da liegst du aber vollkommen daneben

Das Finden eines Elements in einer Liste liegt in O(n), da Suchen in einem Dictionary bei vernünftigen Hashwerten in O(log n) und das macht sich bei vielen (hundert)tausend Anfragen deutlich in der Laufzeit bemerkbar.

nkoehring hat geschrieben:Ich glaube nicht das es effizienter ist, ein zusaetzliches Dictionary zu bemuehen.

Hallo NKoehring!

Innerhalb eines Dictionaries kann **unglaublich schnell** nach einem Schlüssel gesucht werden. Wenn ich den Index eines Eintrags einer Liste nicht weiß, dann muss diese Liste von oben nach unten durchlaufen werden. Das ist im Gegensatz zur Verwendung eines Dictionaries **unglaublich langsam**.

mfg
Gerold

Ja da habt ihr natuerlich beide recht... Irgendwie hab ich da wohl bloedsinnig gedacht, als ich das schrieb.

Aber dann sollte er das Tuple wegwerfen und ganz auf ein Dict umstellen... ich kann mir jedenfalls nicht vorstellen, warum es sinnvoll sein sollte *beides* mit sich zu fuehren.

nkoehring hat geschrieben:@Birkenfeld: Kannst du denn mal kurz und knapp (mit C-Kenntnissen als Voraussetzung) erlaeutern, wie sich Tupel und Lists noch so im Speicher unterscheiden, außer eben das die Liste veraenderbar ist und das Tupel nicht?

Wie gesagt, nur durch die Überallozierung.

Also ich stelle mir das ungefaehr so vor:
Ein Tuple entsteht, indem einfach die zusammenaddierte Bytegroesse des Tuple-Inhalts alloziiert

Pro Objekt ist das ein Pointer.

und das entstandene Objekt nicht mehr angefasst wird. Eine Liste brauch unmengen an Zusatzfunktionen. Sie muss sich staendig neualloziieren und ihren Inhalt veraendern koennen. Das muss ein Tuple nicht.

Diese neu allozierenden Funktionen rufst du ja nicht auf, wenn du eine nichtveränderliche Liste hast. Die Funktionen an sich belegen ja keinen Platz pro Liste.

Aber aendert das etwas an der Geschwindigkeit? Schließlich ist der Abruf eines einzelnen Objektes innerhalb eines Tuples oder einer Liste doch das gleiche. Mache ich also mit einer Liste das gleiche wie mit einem Tuple, sollte es doch speicher- und geschwindigkeitstechnisch keinen Unterschied machen (außer eben bei der erwaehnten Sache mit der Ueberalloziierung, bei großen Listen)... liege ich da richtig?

Ganz genau.

Das deutsche Python-Forum

Warum haben Tupel keine .index(x)-Methode?

Warum haben Tupel keine .index(x)-Methode?

Re: Warum haben Tupel keine .index(x)-Methode?

Re: Warum haben Tupel keine .index(x)-Methode?

Re: Warum haben Tupel keine .index(x)-Methode?

Re: Warum haben Tupel keine .index(x)-Methode?