for Schleife

[mathie]

Hallo,

ich hab eine Frage und zwar angenommen ich habe eine Liste die so aussieht ['0.5 l', '5 l', '10 Stueck', '1 kg', '2 kg', '3 kg', '3 l', '2 Dosen', '0.1 kg'] (sind also alles Einheiten) und ich möchte, dass je nach Einheit eine eigene Liste dafür erstellt wird. Also zum Beispiel: wenn die Einheit "l" ist dann soll die Produktmenge der Liste x hinzugefügt werden, wenn sie "kg" ist dann der Liste y und so weiter. Ich nehme an man macht das mit einer for schleife und dann mit if und elif, ich weiß aber leider gar nicht wie man bei sowas anfängt. Es wäre sehr nett wenn jemand mal eine kleine Hilfestellung geben könnte. Vielen Dank!

[greetings1]

Ich denke, du meinst so etwas:

Code: Alles auswählen

s = ["0.5 l", "5 l", "10 Stueck", "1 kg", "2 kg", "3 kg", "3 l", "2 Dosen", "0.1 kg"]
d = {}
for i, e in enumerate(s, 0):
    x = e.split()
    if x[1] in d:
        d[x[1]].append((i, float(x[0])))
    else:
        d[x[1]] = [(i, float(x[0]))]
for i, key in enumerate(d, 0):
    print(i, key, d[key])

Ausgabe:

0 l [(0, 0.5), (1, 5.0), (6, 3.0)]
1 Stueck [(2, 10.0)]
2 kg [(3, 1.0), (4, 2.0), (5, 3.0), (8, 0.1)]
3 Dosen [(7, 2.0)]

[__blackjack__]

@greetings1: Die Namen sind fast alle schlecht gewählt. Selbst wenn man generische Namen wählt, sollten die aussagekräftiger als einzelne Buchstaben sein.

In der Frage sehe ich nicht warum da eine laufende Zahl mit in die Listen gesteckt werden sollte‽

Magische Indexwerte bei Zugriffen sind nicht schön. Statt ``x[0]`` und ``x[1]`` sollte man das Ergebnis von dem `split()`-Aufruf gleich an sinnvolle Namen zuweisen.

Der Code lässt sich mit einem `collections.defaultdict` vereinfachen.

Wenn man in einer Schleife zu jedem Schlüssel auch den Wert benötigt, sollte man gleich über die Paare iterieren und nicht nur über den Schlüssel.

Code: Alles auswählen

#!/usr/bin/env python3
from collections import defaultdict


def main():
    items = [
        "0.5 l",
        "5 l",
        "10 Stueck",
        "1 kg",
        "2 kg",
        "3 kg",
        "3 l",
        "2 Dosen",
        "0.1 kg",
    ]
    unit_to_amounts = defaultdict(list)
    for item in items:
        amount, unit = item.split()
        unit_to_amounts[unit].append(float(amount))

    for unit, amounts in unit_to_amounts.items():
        print(unit, amounts)


if __name__ == "__main__":
    main()

[mathie]

Ok vielen Dank erstmal! Wenn ich allerdings versuche das zu splitten damit ich den Wert und die Einheit separat habe, kommt immer die Fehlermeldung "object has no attribute split". Woran liegt das?

[__blackjack__]

@mathie: Daran, dass das Objekt keine `split()`-Methode hat. Bei den Quelltexten von greetings1 und mir passiert das aber nicht. Und Deinen Code kennt keiner hier.

[greetings1]

In der Frage sehe ich nicht warum da eine laufende Zahl mit in die Listen gesteckt werden sollte‽

Wir wissen nicht, was er/sie danach damit vor hat. Mit einer ungeordneten Liste könnte ich jetzt nicht so viel machen.

Woanders habt ihr euch beschwert, dass die Bezeichner zu lang seien, insofern kann ich diese Kritik nicht ganz nachvollziehen.

[sparrow]

@greetins 1:

Die Liste ist auch mit der laufenden Zahl weiterhin ungeordnet, denn die Zuweisung der Zahl folgt ja keiner Ordnung - außer dem zufälligen ersten Vorkommen der Einheit.
Das ist höchstens künstlicher Primärschlüssel, der aber unnötig ist, weil die Einheit jedes Elelemt der Liste bereits eindeutig identifiziert.

Was die Namen von Bezeichnern angeht:
Ziel des Syntax und die Mentalität von Python ist es, möglichst leserlichen Code zu schreiben. Wenn man deinen Code mit dem von __blackjack__ vergleicht, kann man den Untschied gut sehen. Dein Code ist ein Puzzle-Stakkato aus vielen Klammern und Ein-Buchtabigen-Bezeichnern, den nachzuvollziehen mal Zeit braucht. Der Code von __blackjack__ ist bereits beim Lesen selbsterklärend. Das sollte immer das Ziel sein.
Bezeichner sollten sprechend sein. Keine kryptischen Abkürzungen, die falsch interpretiert werden können; keine einbuchtabigen Bezeichner, die jeglicher Interpretation strotzen und nach Möglichkeit keine magischen Index-Zugriffe.
Wenn man sich daran hält bekommt man gut zu lesenden und zu verstehenden Code.
Es gibt andere Programmiersprachen in denen man eine Disziplin daraus gemacht hat, möglichst kryptischen Code zu schreiben. In Python ist das unnötig und tatsächlich auch nicht gewollt.

[greetings1]

Keine kryptischen Abkürzungen,

Wir kennen die/ihre Problemdomäne aber nicht, insofern kann ich auch keine aussagekräftigen Variablennamen wählen. Geht es um eine Einkaufsliste? Wenn ja, was soll wie damit geschehen? Geht es um ein Statistik? Geht es um das "Erkennen" einer Liste? Tausend Fragezeichen.

Und s für str, d für dict, e für Element, i für Index, x für Match-Result und k für Key sind nicht ganz "unübliche" Abkürzungen...

[sparrow]

Es gibt keine tausend Fragezeichen. __blackjacks__ Code zeigt doch, wie man sprechende Namen verwendet. Und so ist es in Python üblich. Du kannst das Programmieren gegen Konventionen verteidigen, aber dann programmierst du halt gegen die Sprache.

[__blackjack__]

@greetings1: Das sind in Python keine üblichen Abkürzungen, ausser `i` für einen Index. Da Namen von Grunddatentypen nichts in Namen verloren haben, gilt das natürlich auch für Abkürzungen selbiger. Und wenn `s` für `str` steht, warum wird dann eine Liste daran gebunden?

Und warum ist `x` ein Match-Result? Da hätte ich ja `m` naheliegender gefunden. Bei `x` denke ich eher an eine Gleitkommazahl. Und fände das einen passenden Namen für eine X-Koordinate.

Passende einbuchstabige Namen sind `i`, `j`, `k` für Indizes und `x`, `y`, `z` für Koordinaten. Und das war es im Grunde auch schon. Grenzwertig, also gerade noch so okay, finde ich einbuchstabige Namen mit *sehr* begrenztem Sichtbarkeitsbereich. Beispielsweise Argumente in ``lambda``-Ausdrücken oder in Generatorausdrücken und „comprehensions“. Oder in interaktiven Python-Sitzungen, also bei sehr kurzem, flüchtigem Wegwerfcode.

An der Stelle wo Du beschreibst, dass man nicht weiss wofür das am Ende sein soll, habe ich ja auch mit `items` einen recht generischen Namen gewählt. Aber bei den anderen Namen schien mir das schon recht klar zu sein was die Werte bedeuten. Egal ob das nun einen Einkaufsliste ist, oder irgendeine Lagerstatistik damit gemacht werden soll, oder eine Rezeptverwaltung, oder was auch immer.

Wurde sich an anderer Stelle tatsächlich über die Länge von Namen beschwert oder darüber das sie Anteile enthielten, die keinerlei Informationsgehalt hatten? Also so etwas wie `my`-Präfixe? Denn dann ist das hier genau die gleiche Kritik, die nur indirekt etwas mit der Länge zu tun hat: Namen sollen dem Leser verraten was der Wert dahinter bedeutet. Das heisst sie sollten weder so kurz und/oder kryptisch sein, dass man raten muss, noch sollten sie irgendwelches ”Füllmaterial” enthalten das nichts zum Verständnis beiträgt.

In anderen Programmiersprachen sind bestimmte Abkürzungen, oder überhaupt so kurze Namen vielleicht üblich(er). Das hat oft aber auch historische Gründe (Beschränkung der Bezeichnerlänge durch die Sprache, Editoren ohne Autovervollständigung, wenig Speicher, Sprache die sich eher an Mathematiker richtet, …), oder bei statisch typisierten Sprachen mit ”manifest typing”, wo man zusätzlich zum Namen noch den Typnamen da stehen hat, der auch Information für den Leser transportiert.

[greetings1]

Naja, dann eben so

Code: Alles auswählen

input_str_list = [
    "0.5 l",
    "5 l",
    "10 Stueck",
    "1 kg",
    "2 kg",
    "3 kg",
    "3 l",
    "2 Dosen",
    "0.1 kg",
]
output_dict = {}
for i, elem in enumerate(input_str_list, 0):
    menge, einheit = elem.split()
    menge_f = float(menge)
    if einheit in output_dict:
        output_dict[einheit].append((i, menge_f))
    else:
        output_dict[einheit] = [(i, menge_f)]
for i, key in enumerate(output_dict, 0):
    print(i, key, output_dict[key])

Wie geschrieben, einen eindeutigen Index mit Bezug zur "input_str_list" würde ich beibehalten, da man mit den "Daten" ansonsten doch wirklich nicht viel anstellen kann.

@mathie : Was hast du vor?

[sparrow]

@greetings1: Es ist unüblich bis hinderlich den vermeidlichen Typ des Wertes in den Bezeichner zu schreiben. Der Typ kann sich gerne mal ändern und dann möchte man doch nicht jede Erwähnung im Quelltext ändern.

Diese willkürlich hochgezählte Nummer hat, wie oben schon beschrieben, keinen Mehrwert. Man kann mit den Daten mit und ohne den Wert gleich viel anfangen. Somit ist er sinnlos.

[greetings1]

willkürlich hochgezählte Nummer

lol

Man kann mit den Daten mit und ohne den Wert gleich viel anfangen.

Nein, kann man nicht.

[__deets__]

ROFL. Natürlich kann man mit dem 3ten Wert einer Liste alleine genauso viel anfangen wie mit einem Tupel aus einem völlig zusammenhanglosen Index und dem Wert. Denn der dritte Wert der Einheit “kg” ist der 3te Wert, und ob davor 107543907 steht oder nicht ist komplett irrelevant.

[sparrow]

@greetings1: Dann erleuchte mich mit deiner Weisheit und erzähle mir, warum der Wert nicht willkürlich ist und wie der bei der Weiterverarbeitung helfen soll.
Nochmal: Die einzelnen Elemente sind bereits über die "Einheit" (l/kg/...) eindeutig unterscheidbar. Die kommen ja schon als Schlüssel aus dem dict. "Schlüssel" haben die Eigenschaft eindeutig zu sein.

[greetings1]

Ggf. möchte man wissen, welchen Index der ursprünglichen Liste das Element hatte (also, wo das Element vorkam). Dafür dass hier einige nicht programmieren können kann ich nix...

[__deets__]

Gegebenenfalls möchte man auch die Quersumme der Einträge haben, oder die relative Mondfeuchte im Moment der Verarbeitung. Alles möglich. Stand aber nirgends. Und bloß weil du dir gerne überflüssige Anforderungen ausdenkst heißt das nicht, das andere Leute nicht programmieren können... eher das Gegenteil. Die Welt ist voll von schlechtem Code, den niemand jemals gebraucht hat.