@Kornblumberg: Das sieht alles ein wenig unvollständig und komisch aus.
Bei einer Schleife bei der man vor Beginn weiss oder ermitteln kann wie oft sie durchlaufen wird nimmt man ``for`` und nicht ``while``.
Wo wird `x` das erste mal an einen Wert gebunden und an welchen? 1 oder 0? Falls ja ist `xar` ziemlich überflüssig, denn die Werte 1 bis 1000 aufsteigend, ohne Lücken, braucht man nicht wirklich in einer Liste zu sammeln. Falls man die irgendwann einmal braucht, zum Beispiel zum Plotten, kann man sie auch dann noch mit einem einfachen Ausdruck erstellen.
Einige Namen sind schlecht. `xar`, `yar`, `yM`, `f` — man sollte aussagekräftige Bezeichner verwenden und keine kryptischen Kürzel wo der Leser raten muss was sie wohl bedeuten mögen.
Es gibt Namenskonventionen was Gross- und Kleinschreibung angeht, und auch so einiges andere:
Style Guide for Python Code. Besonders möchte ich da die Einrücktiefe hervorheben: Vier Leerzeichen pro Ebene.
Falls die Samplerate von der Auslese- und Verarbeitungsgeschwindigkeit dieser Schleife abhängen sollte (Deine Beiträge klingen irgendwie so), dann möchtest Du in dieser Schleife wahrscheinlich wirklich nur die Werte auslesen. Nicht nur weil weitere Arbeit hier die Samplerate drücken können, sondern auch weil Datenbanken und unter Umständen sogar Dateien nicht für jeden Schreibvorgang die gleiche Zeit benötigen. Es wäre auch gut wenn man die einzelnen Schritte in verschiedenen Funktionen schreibt und nicht alles als einen Riesencodeklumpen auf Modulebene sammelt.
Bei den ``if``-Bedingungen sind viele Klammern unnötig.
Man vergleicht normalerweise nicht mit literalen Wahrheitswerten. Denn da kommt am Ende nur wieder ein Wahrheitswert heraus und den hatte man ja vorher schon. Das ist entweder immer der gleiche oder aber immer das Gegenteil vom Ausgangswert. Im ersten Fall kann man den Ausgangswert direkt nehmen und im zweiten kann man ``not`` verwenden. Also statt ``if active == False:`` würde man ``if not active:`` schreiben.
Wobei diese ganze `Aktiv`-Geschichte komisch bis falsch aussieht. Der erste Test ist ob `UART` geschlossen ist. Dann wird in Abhängigkeit von `Aktiv` die Verbindung geöffnet. Nur wissen wir ja das sie geschlossen sein muss. Wenn `Aktiv` also `True` ist, dann wird diese geschlossene Verbindung *nicht* geöffnet, aber dann in einer Schleife versucht daraus zu lesen. Das kracht dann mit einer Ausnahme.
Für den Fall das gelesen werden kann, muss `UART` im ersten ``if``-Zweig geöffnet worden sein. Dort wird auch `Aktiv` auf `True` gesetzt. Das ist die einzige Möglichkeit das man zum letzen ``if`` gelangt. Und da *muss* `Aktiv` dann `True` sein, weshalb es sinnlos ist das zu testen.
Kann es sein das `Aktiv` total überflüssig ist wenn man die `isOpen()`-Methode von dem `UART`-Objekt direkt verwenden würde um festzustellen ob man das öffnen oder schliessen muss/kann? Muss das überhaupt sein?
Falls `UART` ein `serial.Serial`-Exemplar ist kann man übrigens über dieses Objekt iterieren und bekommt die Zeilen als Werte geliefert. Das verhält sich da wie Dateiobjekte. Und diese Objekte sind auch Kontextmanager, das heisst man kann die mit ``with`` verwenden und sich diesen ”testen und öffnen und schliessen”-Code ganz sparen.
Werte und Teilzeichenketten mit `str()` und ``+`` zusammenzusetzen ist eher BASIC als Python. Python hat dafür Zeichenkettenformatierung mittels der `format()`-Methode auf Zeichenketten. Weniger Tipparbeit, flexibler, und man sieht auch ohne farbige Syntaxhervorhebung noch einfach wie das Ergebnis wohl aussehen wird und was literale Zeichenkette und was Code ist. Für CSV-Dateien hat Python allerdings auch ein Modul in der Standardbibliothek. Und wenn man im Programm auch plotten möchte hat man fast immer auch eine Abhängigkeit zu `numpy` — dort gibt es auch Funktionen um solche Textdateien zu erstellen.
Und mir wird immer unklarer was die Datenbanktabelle soll. Das macht so keinen Sinn.
. 