@OWT: Wörterbuch ist schon richtig aber halt nicht so wie Du das gemacht hast da Schlüssel mit zwei verschiedenen Bedeutungen rein zu stecken, die man dann am Ende wieder auseinander puzzeln muss. Der Schlüssel sollte die Logger-ID sein und zu allen Daten führen die zu diesem Logger gehören, und nicht Schlüssel die aus Logger-ID und Datumsart zusammengesetzt sind, und dann nur zu den Daten von dieser Art führen. Das macht nur Sinn wenn man Logger-ID und Datumsart auch wirklich so als Schlüssel braucht, nicht wenn man am Ende nur über die Logger-ID zu allen Daten kommen will.
Ja die „saubere Langform“ — Spalten entsprechen Variablen und Zeilen einer Messung/Beobachtung entspricht im groben einer normalisierten Tabelle in relationalen Datenbanken und da ist die Variable Logger-ID eine Spalte, und nicht eine Spalte pro Wert den Logger-ID annehmen kann.
Da würde ich Speicher erst einmal aussen vor lassen, solange das konstant oder linear mehr Speicher ist und kein tatsächlich messbares Problem, und erst einmal Wert auf verständlichen, nicht unnötig komplexen Code legen. Insbesondere bei Numpy und Pandas kann ”optimieren” auch gegenteilige Effekte haben, weil die ja für grössere Datenmengen ausgelegt sind und eine interne Operation von Numpy oder Pandas ist in der Regel schneller als wenn man sich Teile davon ”aussen” in Python nachbastelt. Darum verwendet man ja Numpy & Co. Selbst wenn man am Ende die „Breite“ Form statt der Langform haben möchte, würde ich diese Umformung mit Pandas machen, denn sonst muss man ja auch von Hand noch das auffüllen von Zellen machen bei denen Werte fehlern, und dann wahrscheinlich für jeden Logger den Datensatz erneut mit dem schon vorhandenen zusammenführen, was am Ende mehr Speicher und Rechnenleistung brauchen kann, als wenn man die ensprechenden Pandas-Operationen dafür verwendet.
IN ist SQL und der Unterschied zwischen per Hand SQL als Zeichenkette basteln, und das SQLAlchemy machen zu lassen, ist dass man bei SQLAlchemy einfach die Liste mit den Logger-IDs angibt und das war's. Bei SQL als Zeichenkette muss man eine der länge der Liste entsprechende Anzahl von Platzhaltern erstellen und die Liste an passenden Stelle in die Liste der Werte beim `execute()` ”flach” einbauen. Also nicht die Liste als Elemente, sondern die Elemente der Liste einzeln mit den anderen Werten. Das macht mehr Arbeit und ist ein bisschen fehleranfälliger, weil man erst die Liste der Platzhalter in der Zeichenkette mit dem SQL hat, und dann eine Liste der Werte, und beides muss in Anzahl und Reihenfolge zusammen passen.
``+=`` macht ja gerade nicht das was man da eigentlich machen will, sondern ist umständlicher und hat am Ende nur den gleichen Effekt. Was auch noch undurchsichtig und überraschend ist, denn eigentlich erwartet man ja, dass ``a += b`` äquivalent zu ``a = a + b`` ist, was in diesem Fall auch nicht stimmt, denn es ist bei Listen äquivalent zu ``a.extend(b)``. Was auch der Grund ist warum ich selbst wenn ich diesen Effekt haben will, nicht ``+=`` sondern die Methode verwende, die tut was ich dann will und verwirrt auch nicht, weil man bei ``+=`` eigentlich eine andere Semantik erwartet hätte.
Das ``+=`` nicht das macht was Du willst, sieht man ja am nächsten Argument, dass die einelementigen Listen nicht unnötig seien, weil ``+=`` sonst nicht macht was Du willst. Sie sind eben doch überflüssig weil ``+=`` hier die falsche Operation ist. `append()` ist das was gewollt ist, und es sagt das auch ganz klar und deutlich was es macht. Im Gegensatz zu ``+=``, was auf Listen verwirrend implementiert ist.
Das macht man so, und das machen alle so, ist übrigens ein valides Argument. Konventionen und idiomatischer Code tragen zur Kommunikation und zum leichteren Verständnis von Code bei. Das ist ein handfester Mehrwert und nicht reine Kosmetik oder Dogma.
Hinterfragen ist okay und wichtig, dabei lernt man was, aber wenn man Leuten die helfen wollen, immer erst mal ein „okay die Leute die das schon lange machen, haben gesagt das macht man anders, aber ich mache trotzdem so weiter bis mich da jemand an die Hand genommen und 100% überzeugt hat“, insbesondere bei so einfachen Sachen wie `append()` statt ``+=``, also wo eine Änderung nichts kostet, führt das irgendwann dazu das keiner mehr Lust hat zu helfen.
Übrigens waren gar nicht die überflüssigen einelementigen Listen beim ``+=`` gemeint, sondern das hier:
Code: Alles auswählen
alle_messdaten[header1] = [messwerte]
alle_messdaten[header2] = [zeitpunkte]