liste als key in dictionary

[blutigeranfaenger]

Hallo zusammen,
ich möchte gerne zwei listen zu einem dictionary vereinen:

Code: Alles auswählen

#!/usr/bin/env python3
l_a = [ [0, 1, 2, 3], [0, 1, 2, 4], [0, 1, 2, 5]]
l_b = [1,2,3]

mydict = dict(zip(l_a,l_b))
Das klappt so nicht, ich weiß, eine Liste kann kein key in einem Wörterbuch sein.
Gibt es dennoch einen Weg, das gewünschte Ziel zu erreichen und wie könnte dieser Weg gehen?
Danke für eure Tipps!

[Dennis89]

Hallo,

so?

Code: Alles auswählen

Python 3.10.7 (main, Sep  7 2022, 00:00:00) [GCC 12.2.1 20220819 (Red Hat 12.2.1-1)] on linux
l_a = [ [0, 1, 2, 3], [0, 1, 2, 4], [0, 1, 2, 5]]
l_b = [1,2,3]
list_to_dic = {}
for index, key in enumerate(l_b):
    list_to_dic[key] = l_a[index]
    
print(list_to_dic)
{1: [0, 1, 2, 3], 2: [0, 1, 2, 4], 3: [0, 1, 2, 5]}

Grüße
Dennis

[__deets__]

Du kannst die Listen zu Tupeln machen, die gehen durch ihre immutability als Keys.

[blutigeranfaenger]

Ja, super, das hat funktioniert, vielen Dank!

[Dennis89]

Damit der Vorschlag von @__deets__ auch noch hier steht:

Code: Alles auswählen

l_a = [(0, 1, 2, 3), (0, 1, 2, 4), (0, 1, 2, 5)]
l_b = [1, 2, 3]
list_to_dict = dict(zip(l_b, l_a))
print(list_to_dict)
{1: (0, 1, 2, 3), 2: (0, 1, 2, 4), 3: (0, 1, 2, 5)}

War das so gemeint?

Grüße
Dennis

[__deets__]

Nein. Du hast dir hier die Freiheit genommen, Schluessel und Werte umzudrehen. Das ist etwas komplett anderes, und loest die Aufgabe nicht. Egal, ob dann die Werte Tupel statt Listen sind.

Es geht darum, das die Schluessel Tupel sein muessen, weil es aus technischen und logischen Gruenden nicht moeglich und sinnvoll ist, vereaenderbare Schluessel zuzulassen. Und natuerlich muessen die Schluessel nach wie vor prinzipiell gleich sein, ich will nicht nach 1 schauen, ich will [0, 1, 2, 3] nachschlagen.

[Dennis89]

Achsoooo, da habe ich den Eingangspost falsch verstanden und dann war ja schon mein erster Post Mist.

Danke für die Verbesserung.

Grüße
Dennis

Edit:

Du hast dir hier die Freiheit genommen, Schluessel und Werte umzudrehen.

So lassen sich Probleme einfacher lösen

[DeaD_EyE]

Die keys eines dicts müssen immutable sein. Ein set kann man nicht als key nehmen, aber ein frozenset geht. Eine Tuple geht auch, da sie nicht veränderbar ist.

[kbr]

Tuple sind ein Grenzfall: sollten die Inhalte eines Tuple mutable sein, dann geht es gleichfalls nicht.

[__deets__]

Grenzfall wuerde ich das jetzt nicht nennen. Der Schluessel muss einfach transitiv immutable sein. Letztlich folgt das aus der Notwendigkeit fuer Schluessel vergleichbar zu sein. Und der ==-Operator ist fuer Tupel elementweise definiert, gleiches gilt fuer Listen. Womit ein Tupel mit einer Liste als Element nicht zulaessig ist, denn die Liste liesse sich ja nachtraeglich veraendern, und waere nicht mehr gleich.

[kbr]

Das meine ich ja: der Datentyp Tuple selbst is immutable; dies muss aber auch für den Value des Tuples gelten, damit es als Key verwendbar ist.

[bords0]

Es geht letztlich nicht um mutability sondern um hashability. Also mutable darf es schon sein, solange es auch hashable ist.

Mit selbst definierten Klassen kann man das durchaus machen. Es ist nach meiner Erfahrung aber nur selten sinnvoll.

[kbr]

Hashable allein genügt nicht, es muss auch stets der gleiche hash-Wert erzeugt werden. Daher scheiden Datentypen mit mutablen Inhalten als Keys aus.

[DeaD_EyE]

Tuple sind ein Grenzfall: sollten die Inhalte eines Tuple mutable sein, dann geht es gleichfalls nicht.

Stimmt. Auf die Idee, so etwas zu machen, bin ich noch nie gekommen.
Dach höchste aller Gefühle: Tuple als Key, wobei die Tuple ausschließlich einen Datentypen enthält (int z.B.).

Hier mal etwas anderes komisches, dass halb funktioniert.
Der Liste wird trotz einer Exception das Objekt hinzugefügt (== list.extend).

Code: Alles auswählen

tup = (1, 2, [])
tup[-1] += [1]

TypeError: 'tuple' object does not support item assignment

Danach ist das letzte Element: [1]

[bords0]

Hashable allein genügt nicht, es muss auch stets der gleiche hash-Wert erzeugt werden. Daher scheiden Datentypen mit mutablen Inhalten als Keys aus.

Das ist nicht korrekt. Um key in einem dictionary zu sein, reicht es aus, wenn hash() einen Wert liefert (d.h. wenn man __hash__() geeignet implementiert). Wenn sich der hash-Wert ändert, findet man den Schlüssel nicht mehr, das sollte man also auf keinen Fall tun. Der hash-Wert darf also nicht von den mutablen Teilen abhängen.

Ich habe z.B. schon gesehen, dass __hash__ die id zurückgibt.
Man könnte aber auch den hash von zwei Attributen verwenden, und alle anderen Attribute könnten dann veränderbar sein.
Oder der hash ist zwar veränderlich, aber die Objekte werden nicht verändert, während sie in ein set gesteckt werden oder so.

Wichtig: Aus Gleichheit von Objekten muss immer auch die Gleichheit der hashes folgen. (Laut Doku die einzige erforderliche Eigenschaft von __hash__().)
https://docs.python.org/3/reference/dat ... t.__hash__

[bords0]

Code: Alles auswählen

tup = (1, 2, [])
tup[-1] += [1]

TypeError: 'tuple' object does not support item assignment

Danach ist das letzte Element: [1]

Das liegt am augmented assignment. Das macht die Liste größer, und dann nochmal die Zuweisung, "assignment" eben, auch wenn es "augmented" ist. Verwirrend, aber hat Methode
In Langform:

Code: Alles auswählen

tup = (1, 2, [])
# Langform von tup[-1] += [1]
temp = tup[-1]
temp += [1]  # geht noch
tup[-1] = temp  # TypeError

[__blackjack__]

@bords0: Das ist im Grunde doch korrekt. Du schreibst ja selbst das , deren Hashwert sich ändert, dann nicht mehr wiedergefunden werden. Um das sinnvoll als verwenden zu können, darf sich der Hashwert nicht ändern, denn sinnvoll wäre ja schon, das man auch wiederfindet.

[__blackjack__]

Ist natürlich ein Implementierungsdetail, aber die Implementierung von `object.__hash__()` ist nahe dran die ID als Hash-Wert zu liefern:

Code: Alles auswählen

In [221]: a = object()

In [222]: hex(id(a))
Out[222]: '0x7f5d2454d570'

In [223]: hex(hash(a))
Out[223]: '0x7f5d2454d57'

Der Hash-Wert ist die ID um 4 Bits nach rechts verschoben. Und die ID (ebenfalls Implementierungsdetail) ist die Speicheradresse. Ich vermute mal Objekte sind mittlerweile mindestens 16 Bytes gross. Jup:

Code: Alles auswählen

In [224]: a.__sizeof__()
Out[224]: 16

[Sirius3]

@DeaD_EyE: das Assignment ist wichtig, denn wenn man

Code: Alles auswählen

werte = [1, 2, 3]
werte[2] += 1

möchte man ja, dass 4 in der Liste steht, aber das Objekt 3 ist unveränderlich, += muß also ein neues Objekt zurückliefern.

[bords0]

@bords0: Das ist im Grunde doch korrekt. Du schreibst ja selbst das , deren Hashwert sich ändert, dann nicht mehr wiedergefunden werden. Um das sinnvoll als verwenden zu können, darf sich der Hashwert nicht ändern, denn sinnvoll wäre ja schon, das man auch wiederfindet.

"Mutable Inhalte" ist nicht das gleiche wie "veränderlicher Hashwert".

Natürlich sollte man den Hashwert nicht ändern, wenn man den alten noch braucht.