Nein, 2.x wird davon nicht profitieren, siehe Issue 7753.

Die Callback-Funktion muss einen wahren Wert zurückgeben, damit sie erneut aufgerufen wird.

Ja, meine Frage war wohl eher, warum eigentlich Prozesse. Jedenfalls kannst du nicht einfach die Gtk-Hauptschleife in einem anderen Prozess laufen lassen. Das heißt, können schon, bringt dir aber nichts, weil dein ursprünglicher Prozess auch eine Hauptschleife braucht. Oder alle GUI-Manipulationen m...

`subprocess.call()` wartet eigentlich, bis der Prozess fertig ist. Es wird ja auch nur der Return-Code vom Prozess zurückgegeben und kein `Popen`-Objekt.

Bitte achte in Zukunft darauf, Probleme möglichst genau zu beschreiben und möglichst auf ein Minimum zu reduzieren, so dass du dann *ausführbaren* Code zeigen kannst, mit dem man das Problem reproduzieren kann. Bei deinem ersten Post sprichst du noch von Threads -- in deinem letzten Beispiel sind ab...

Was sind denn einfache Fälle? `os.popen()` benutzt halt immer eine Shell, das mag man in der Regel vermeiden.

@BlackJack: Mit become.py natürlich.

Tut mir leid für den unqualifizierten Beitrag, ich konnte nicht widerstehen.

Wobei man die marshal-Module relativ einfach aus den jeweiligen Python-Versionen extrahieren kann und als eigenständiges Py-Modul bauen kann, ebenso das dis-Modul. Wenn man also wirklich nur einen Blick auf ein Modul werfen mag und nicht unbedingt den Quelltext direkt braucht, kann man das folglich ...

Dabei wird das "populate-popup"-Signal ausgelöst, dem das Menü übergeben wird, damit solltest du das Menü vor dem Anzeigen dann manipulieren können.

Vielleicht magst du ja etwas Code zeigen, damit man auch sieht, was du machst. Im Allgemeinen gibt es bei GUIs und Threads doch einiges zu beachten, ich bin mir sicher, dass die Forensuche da einige Beiträge finden dürfte.

Ja -- wenn man eben `PySys_SetArgv` oder vergleichbares aufgerufen hat.

Da gibt es nichts zu zeigen. `Py_GetPath()` gibt bei jedem Aufruf das gleiche zurück wie beim vorigen Aufruf.

Warum benutzt der OP nicht einfach `PySys_SetArgv` oder manipuliert `sys.path` direkt?

Warum sollte es? Das, was `Py_GetPath` zurückgibt, ist *nicht* `sys.path`.

Edit: Wobei die Dokumentation das natürlich ein wenig suggeriert, das ist wohl etwas unglücklich.

Edit: Jetzt nicht mehr.

`Py_GetPath()` gibt wirklich nur ein paar wenige Default-Pfade zurück. Beim Initialisieren von Python wird aber auch das Modul [mod]site[/mod] geladen und erst das hängt das site-packages-Verzeichnis an `sys.path` an. Nach dem Starten steht in `sys.path` also viel mehr, als `Py_GetPath()` zurückgibt...

Das Problem dürfte eher die Kombination Threads und pynotify sein, `raw_input()` gibt den GIL schon frei und mit gobject alleine funktioniert das auch.

Einfach mit 2.6 sauber programmieren, dann kann man es mit 2to3 automatisch übersetzen lassen.

@hendrikS: >>> class List(list): ... def __hash__(self): ... return hash(tuple(self)) ... >>> key = List() >>> D = {key: 42} >>> D[key] 42 >>> key.append('Oh noes') >>> D[key] Traceback (most recent call last): File "<input>", line 1, in <module> KeyError: ['Oh noes'] >>> D[D.keys()[0]] Tr...

Das mit dem neu laden geht spätestens dann schief (im Sinne von es wird einfach nicht neu geladen), wenn man es mit Modulen zu tun hat, die nicht in Python geschrieben sind, zumindest unter Plattformen, bei denen diese Module mit `dlopen()` geladen werden. Wie sma schon sagte, wirklich alles neu lad...

Wenn du Python 2.5 benutzt, fehlt da ein __future__-Import (``from __future__ import with_statement``).

Und mittlerweile gibt es auch Version 0.9.6.2. Zahlreiche Bugs wurden gefixt und es wurde backward completion (mit Shift+Tab kann man in umgekehrter Reihenfolge durch Vervollständigungsvorschläge wandern) sowie auto dedentation hinzugefügt. Desweiteren gibt es jetzt auch ein Gtk+-Frontend, das zwar ...