@IncepTer: Wenn `len()` 4 als Ergebnis hat, dann kann man auch auf den Index 1 zugreifen. Das kann also nicht stimmen. Du ermittelst dann nicht die Länge der Liste auf die Du dann auch zugreifst.
Anmerkungen zum Quelltext: Es ist in Python unüblich Leerzeichen zu setzen um Gleichheitszeichen auszurichten. Würde ich auch in anderen Programmiersprachen nicht machen, weil das unnötig Arbeit nach sich zieht wenn sich der längste Name in so einem Block ändert. Entweder weil man den Namen selbst ändert oder die Zeile entfernt oder eine Zeile mit einem längeren Namen hinzu kommt. Dann hat man plötzlich ein Diff bei dem sich Zeilen ”ändern” in denen sich eigentlich gar nichts geändert hat.
Man nummeriert keine Namen durch. Wenn man das tut will man sich passende Namen ausdenken oder gar keine einzelnen Namen, sondern eine Datenstruktur verwenden. In diesem Fall scheint es aber einfach nur ganz furchtbar unsinnig überall eine 1 dran zu pappen.
Grunddatentypen haben in Namen nichts verloren. Wenn man im Laufe der Programmentwicklung den Typen ändert, dann hat man entweder falsche, irreführende Namen im Programm, oder man muss überall im Programm die betroffenen Namen ändern. Was bei ausgerichteten Gleichheitszeichen bei Zuweisungen dann noch weitere Änderungen nach sie ziehen kann.
Man sollte Abkürzungen und kryptische Prä- und Suffixe vermeiden. Der Leser sollte nicht rätseln müssen was `p_` und `s_` wohl bedeuten mag.
In Python kann man wirklich sehr oft Indexzugriffe vermeiden. Statt da von Hand die Indexwerte 0 bis 3 hin zu schreiben, kann man auch einfach “unpacking“ auf die Namen bei der Zuweisung machen. Die ganzen sechs Zeilen aus dem ersen Codeschnippsel lassen sich inklusive öffnen und schliessen der Datei in zwei Zeilen ausdrücken:
Code: Alles auswählen
with open("s1.txt", encoding="ascii") as file:
s_status, s_wert, p_an, pump_zaehler = file.read().split("|")
Bei Textdateien sollte man immer explizit eine Kodierung angeben. Und man sollte sie immer schliessen, was im zweiten Beispiel nicht passiert — und auch der Grund für das Problem sein kann. Solange die Datei nicht geschlossen wird, muss sie auch noch nicht komplett geschrieben sein. Dann können immer noch Daten im Ausgabepuffer des schreibenden Programms liegen.
Beim zweiten Codeschnippsel ist die Einrückung kaputt — ich vermute mal der Start des externen Programms soll auch noch mit unter das erste ``if`` fallen‽
Es gibt keinen Grund mit ``shell=True`` eine unnötige Shell zwischen den laufenden und den gestarteten Prozess zu setzen. Das ist eine unnötige Fehlerquelle — man weiss beispielsweise nicht ob Ausgaben oder Rückgabecode von der Shell oder von dem in ihr gestarteten Prozess stammen. Das ist ein völlig unnötiges Risiko.
Statt `Popen` würde man hier auch eher `run` verwenden, denn das `Popen`-Objekt wird ja gar nicht wirklich verwendet.
Statt ``split("\n")`` sollte man die `splitlines()`-Methode verwenden, denn da Zeilen mit "\n" abgeschlossen werden, hat man bei ``split("\n")`` am Ende immer eine leere Zeichenkette in der Liste:
Code: Alles auswählen
In [30]: text = """\
...: one
...: two
...: three
...: """
In [31]: text
Out[31]: 'one\ntwo\nthree\n'
In [32]: text.split("\n")
Out[32]: ['one', 'two', 'three', '']
In [33]: text.splitlines()
Out[33]: ['one', 'two', 'three']
Falls das ``DB.py``-Programm mit dem selben Python ausgeführt werden soll wie das aus dem es aufgerufen wird, dann würde ich da nicht "python3" in die Argumentliste schreiben, sondern ``sys.executable``.
Code: Alles auswählen
if "S1" in wert:
with open("s1.txt", "w", encoding="ascii") as file:
file.write(wert)
#
# TODO If the subprocess should use the same Python than this
# program, then use `sys.exetutable` instead of "python3".
#
result = subprocess.run(
["sudo", "python3", "DB.py"],
stdout=subprocess.PIPE,
universal_newlines=True,
)
for line in result.stdout.splitlines():
if not line.startswith("#"):
print(line)
Ist die externe Datei wirklich nötig? Man kann die Daten ja auch ohne Datei dem gestarteten Prozess über sein `stdin` übermitteln (`input`-Argument von `run()`) oder als Argument.
Oder wie sparrow schon schrieb, das ganze gar nicht über einen zusätzlichen Prozess lösen.
