Subprozess unter Windows

[lise]

hallo (Beginner in Not...),

vielleicht hat einer einen hilfreichen Tip für mich? Mein Problem ist folgendes: Ich möchte unter Win32 aus meinem Python Programm

(1) ein weiteres .py aufrufen und
(2) dieses aus meinem Hauptprogramm heraus auch wieder terminieren.

korriegiert mich bitte, falls ich falsch liege:
Erst einmal benutze ich win32api, gegebenenfalls auch noch das subprocess-modul (?). über win32api sollte ich doch Zugang zu den Windows eigenen Befehlen wie OpenProcess und TerminateProcess haben. So weit, so gut. Damit ließen sich meine Probleme ja lösen. Nur benötige ich für OpenProcess und TerminateProcess die PID, die ich über die Windows-Befehle dadurch erhalten würde, daß ich den Prozess zu Beginn der Prozedur erst mal erstelle mit CreateProcess - der würde mir die PID zurückgeben. Nur leider gibt's sowas nicht bei win32api
Ich bräuchte also irgendeine Lösung, mit der ich einen Platzhalter für einen Subprozess erstelle und mir hierfür die PID zurückgegeben wird - und das Ganze für Windows.

(Noch besser wäre allerdings ein Lösungsansatz, der auf Plattformunabhängigkeit hinausläuft)

kann jemand helfen?

lg,
lise

[Leonidas]

Starten kannst du es mit subprocess, das liefert dir die PID, beenden kannst du es dann mit den Win32API-Funktionen.

[jens]

Mal eine andere Frage. Warum ist eigentlich nicht schon die win32api mehr in Python integriert. Es gibt einen ganzen haufen an Methoden, die nur unter Unix funktionieren, wie z.B. os.kill
Ich stecke da nicht so tief drin, aber kann man nicht eine reihe von diesen nur-Unix-Methoden mit hilfe der win32api genau so auch unter Windows umsetzten?

Warum wurde das nicht gemacht? Weiß jemand ob sich in Python 3k das ändern wird?

[Leonidas]

Warum wurde das nicht gemacht?

Grauenhafte Dokumentation, total unpythonisch etc. Also so etwas möchte ich wirklich nicht in der stdlib haben. Die am meisten fehlenden Funktionen kann man ja implementieren, wie os.kill über die Win32API unter Windows aber bitte nicht den ganzen Rest.

Übrigens, ActivePython ist mit pywin32.

[prof_weirdo]

Warum wurde das nicht gemacht?

Grauenhafte Dokumentation, total unpythonisch etc. Also so etwas möchte ich wirklich nicht in der stdlib haben. Die am meisten fehlenden Funktionen kann man ja implementieren, wie os.kill über die Win32API unter Windows aber bitte nicht den ganzen Rest.

Übrigens, ActivePython ist mit pywin32.

Dokumentation kann man schreiben und praktisch wär das nach meiner Meinung schon, unpythonisch hin oder her.

[apollo13]

unpythonisch hin oder her.

Genau das soll es eben nicht sein^^

[birkenfeld]

Es gibt einen einfachen Grund: Wäre pywin32 im Core, müsste es von den Core-Devs gemaintaint werden (huh, Denglisch^HNeudeutsch vor...). Und den allermeisten von denen geht es jedoch so: "Isch abe aber gar kein Windows..."

[prof_weirdo]

Es gibt einen einfachen Grund: Wäre pywin32 im Core, müsste es von den Core-Devs gemaintaint werden (huh, Denglisch^HNeudeutsch vor...). Und den allermeisten von denen geht es jedoch so: "Isch abe aber gar kein Windows..."

Gut. Das ist ein schlüssiges Argument.

Nachtrag: Wobei Windows zu ignorieren eigentlich dumm ist.

[jens]

Nachtrag: Wobei Windows zu ignorieren eigentlich dumm ist.

Das meine ich aber auch! Nicht das ich Windows so toll finde. Aber ignorieren kann und sollte man es nicht. Ist das selbe Problem wie mit MySQLdb für Windows. Es wirft einfach kein gutes Licht auf Python

[birkenfeld]

Wenn es so viele Leute gibt, die Windows und Python verwenden, dann wird doch wohl einer von denen in der Lage sein, einen MySQLdb-Port für Windows beizusteuern.

Ich sehe es als OpenSource-Autor als meine Freiheit an, bestimmte Dinge einfach *nicht* zu tun, wenn ich dazu keine Lust oder keine Ressourcen habe.

[jens]

Mit dem zweiten Satz hast du natürlich vollkommen Recht! Da stimme ich dir also zu. Dennoch ist es nicht nur für die Python Community schlecht oder meinst du nicht?

[prof_weirdo]

Wenn es so viele Leute gibt, die Windows und Python verwenden, dann wird doch wohl einer von denen in der Lage sein, einen MySQLdb-Port für Windows beizusteuern.

Ich sehe es als OpenSource-Autor als meine Freiheit an, bestimmte Dinge einfach *nicht* zu tun, wenn ich dazu keine Lust oder keine Ressourcen habe.

Es kritisiert ja auch niemand Dich als Open Source-Autor. Die Sache ist einfach das eine Programmiersprache die Windows auf diese Art nicht beachtet deutlich schlechtere Karten hat sich durchzusetzen, denn die meisten Computer (abgesehen mal von Servern) haben nunmal Windows am laufen. Und mit "die meisten" ist schliesslich nicht eine kleine Überzahl gemeint , sondern eine vernichtend grosse.

[Leonidas]

(abgesehen mal von Servern)

Und wieviele dieser nicht-Server haben MySQL laufen? Eine verschwindend geringe Anzahl.

[birkenfeld]

Es kritisiert ja auch niemand Dich als Open Source-Autor. Die Sache ist einfach das eine Programmiersprache die Windows auf diese Art nicht beachtet deutlich schlechtere Karten hat sich durchzusetzen, denn die meisten Computer (abgesehen mal von Servern) haben nunmal Windows am laufen. Und mit "die meisten" ist schliesslich nicht eine kleine Überzahl gemeint , sondern eine vernichtend grosse.

Die Programmiersprache an sich hat nichts mit MySQLdb zu tun -- Python liefert gar kein MySQL-Modul mit.

Und genau deswegen, weil auf den vielen vielen Computern Windows läuft, frage ich mich ja auch, warum keiner davon auch ein Windows-Build von MySQLdb machen kann. <sarkasmus>Entweder sind die alle inkompetent oder den kompetenten Leuten ist MySQL egal.</sarkasmus>

[nkoehring]

Ich wuerde (um mal zurueck zum Thema zu kommen) einfach das Pythonteil als Modul einbinden und starten... notfalls waeren auch exec- oder eval-Funktionen moeglich, aber das ist ziemlich unsauber (oder?).

Siehe Windoze vs Linux:
Mir ist die Windoze-Welt totaaaal egal ^^

[gerold]

Mal eine andere Frage. Warum ist eigentlich nicht schon die win32api mehr in Python integriert.

Hallo Jens!

Das habe ich mir auch oft schon gedacht, aber andererseits denke ich, dass es besser war, `ctypes` in Python zu integrieren. So können sich versionsunabhängigere und hoffentlich besser dokumentierte Projekte etablieren, als es pywin32 ist. Die Dokumentation zu pywin32 ist wirklich sehr schlecht. Teilweise wurden Dinge nur halb umgesetzt, so dass man zwar glaubt, es müsse funktionieren, aber später drauf kommt, dass es doch nicht so wie erwartet funktioniert.

Ich hoffe, dass in Zukunft mehr ctypes-abhängige Schnittstellen entstehen. Diese wären nämlich in Python geschrieben und nicht so sehr davon abhängig, dass irgendjemand etwas kompiliert oder ein Maintainer endlich das schon lange fertige Windows-Binary in die SourceForge-Website stellt.

lg
Gerold