IDLE Reimagined

[jens]

Die IDLE ist ja allgemein nicht zu empfehlen... Aber vielleicht sollte man sich mal Gedanken machen, wie sie denn besser sein könnte.

Das Versucht das Projekt "IDLE Reimagined" -> https://github.com/asweigart/idle-reimagined

[darktrym]

Kannst du Ausführungen machen, was an Idle nicht stimmt? Ich fande z.B. nicht das den Tutorials von Ryan Shae etwas gefehlt hat.

[BlackJack]

@darktrym: Viele Anfänger fallen darauf herein dass die Shell kein Editor ist, aber Laden und Speichern vom Fensterinhalt erlaubt. Um den Interpreter für Code den der Benutzer ausführt von dem zu trennen der IDLE selbst ausführt muss IDLE über Sockets kommunizieren was bei Windows an einer Firewall scheitern kann. Oder man führt alles im selben Interpreter aus, dann bekommt man Probleme mit Tk-Programmen weil IDLE selbst ja eines ist. Wenn man Module ausführt werden die alle im selben Interpreter ausgeführt, das heisst alles was auf Modulebene definiert ist, landet im gleichen Namensraum und lungert da auch weiterhin herum solange man das nicht explizit zurücksetzt. Auch in Python 2 kann man Namen mit Umlauten schreiben. Was natürlich ausserhalb von IDLE dann auf die Nase fällt.

Das sind jedenfalls so die Punkte die mir am unangenehmsten aufgefallen sind, als ich das letzte mal IDLE etwas näher betrachtete.

[jens]

Das stimmt aber IMHO nicht mehr. Ich meine Skripte werden per subprocess ausgeführt...

[BlackJack]

@jens: Was davon stimmt nicht mehr? Wenn man F5 im Editor drückt wird das Modul ausgeführt und zwar im gleichen Namensraum wie die interaktive Shell. Das heisst Sachen die ich dort definiert habe, kann ich im Modul einfach so verwenden und umgekehrt nachdem das Modul einmal ausgeführt wurde. Gerade mit IDLE für Python 2.7 und Python 3.2 ausprobiert.

[jens]

Wie gesagt, ich meine es wird subprocess verwendet.

Ich sehe auch zwei Prozesse die laufen, wenn ich die IDLE starte. Wenn ich dann mit F5 ein skript starten lasse, wird ein neuer prozess erstellt.

(Python 3.4.2 unter Windows)

EDIT: Siehe auch: https://hg.python.org/cpython/file/28fe ... lib/run.py

Ich kann auch mein Tk Skript von http://www.python-forum.de/viewtopic.php?f=11&t=35134 ohne Probleme ausführen.

Wie kann man denn ein Problem provozieren?

[BlackJack]

@jens: Es wird ein Subprocess gestartet der über Sockets kommuniziert und in dem dann alle Skripte und die Shell ausgeführt wird, halt in *dem* Namensraum. Das trennt nicht die Shell und die Skripte voneinander, sondern den Interpreter in dem IDLE ausgeführt wird von dem Interpreter in dem der Code vom Benutzer ausgeführt wird. Das ist das was unter Windows manchmal nicht funktioniert bevor man die Firewall so eingestellt hat das IDLE mit sich selbst über Sockets kommunizieren darf, was ich ja auch als Punkt aufgeführt hatte.

Zumindest ist das bei den IDLEs die ich installiert habe so. Mag sein dass das in 3.4 anders ist, das kann ich nicht überprüfen ohne mein halbes Betriebssystem selbst neu zu kompilieren.

[jens]

Hab mal in meinen Firewalleinstellungen nachgesehen. Ich kann keine extra Regel für die IDLE oder für Python finden.
Sehen kann ich allerdings, das über TCP gesprochen wird.

Aber die alte Geschichte, das man kein Tkinter mit der IDLE entwickeln sollte, stimmt somit nicht mehr, oder?

Ich denke mal für den Debugger und Class-Brower muss man halt irgendwie mit dem auszuführenden Skript kommunizieren.
Die Frage wäre: Wie kann man es anders machen?

Vielleicht wäre eine separate run Methode hilfreich, die halt wirklich nur per subprocess den Python interpreter mit dem skript startet und stdout/stderr anzeigt.

Allerdings: Wenn man sich den Quellentext der IDLE ansieht, gibt es dort einige Merkwürdigkeiten. Vermutlich, weil es halt schon alt und nie richtig neu gemacht wurde?

[BlackJack]

@jens: Das mit der Firewall taucht immer mal wieder auf. Das ist vielleicht auch von der Windowsversion und den Einstellungen abhängig, oder ob man sich neben der windowseigenen Firewall noch andere Sicherheitsprodukte installiert hat.

Klar muss man für einen Debugger dann mit dem Prozess kommunizieren, das ist doch aber kein Grund das *alles* im gleichen Namensraum läuft. Man kann das ja auch als Feature auffassen wenn man IDLE zum Beispiel einfach nur als erweiterten Taschenrechner verwendet oder ”live” irgendwelche Daten verarbeitet und es nicht wichtig ist, dass der Vorgang ohne weiteres wiederholbar ist. Um das nutzen zu können ohne Überraschungen zu erleben muss man aber a) wissen was Namensräume sind und wie die normalerweise ausserhalb von IDLE in Python funktionieren und b) das sich IDLE so anders verhält. a) wissen Anfänger nicht und b) ist für erfahrenere Python-Programmierer überraschend.

[jens]

PyCon 2015's Education Summit: https://www.youtube.com/watch?v=u58DiW_t2lM