Das deutsche Python-Forum

Hallo,

ich hab gerade zufällig PyGuile gefunden und möchte den Link einfach noch einbringen, weil Guile ja auch erwähnt wurde

Nebenbei, ich fänd ein Python-Binding für tinypy recht interessant. Hacken an tinypy selbst muss man glaube ich nichts, wenn ich das richtig sehe, hats ja noch keine "batteries included - yet".
Die Lösung mit einem 'Normal-Python' und ein paar Verboten ist aber sicherlich die Unsauberste ... ich denke auch nicht, dass man das effektiv 'sicher' bekommt :/

Gruß,

Fred

fred.reichbier hat geschrieben:Die Lösung mit einem 'Normal-Python' und ein paar Verboten ist aber sicherlich die Unsauberste ... ich denke auch nicht, dass man das effektiv 'sicher' bekommt :/

Ja, der hier vorgeschlagene Ansatz ist eher ein Python zu verwenden, wo eben viele Sachen auskompiliert. PyGuile geht aber den anderen Ansatz, es ruft aus dem Guile-Interpreter Python auf, zumindest habe ich es so verstanden.

Oh, du hast recht. Naja, wenigstens sagt der Autor hier, dass PyGuile später auch bidirektional funktionieren soll.

fred.reichbier hat geschrieben:Oh, du hast recht. Naja, wenigstens sagt der Autor hier, dass PyGuile später auch bidirektional funktionieren soll.

Besser noch, er linkt auf Schemepy, ein in Python eingebettetes Scheme. Wenn man ins das Archiv schaut, dann stellt man fest dass es sogar noch besser ist als erwartet, es unterstützt mehrere Schemes, momentan Guile und MzScheme (also das von PLT Scheme). Es soll sogar pure-Python Fallbacks haben, vermutlich über ctypes. Mein Lieblingsscheme mit Python kombiniert ist super, mal sehen wo ich das verwenden kann

Übrigens, der Tarball ist wohl aus versehen zweimal mit gzip gepackt, also falls euer Packprogramm da meckert, einfach einmal gunzip laufen lassen.

Edit: Der Fallback scheint ein selbstgebautes Scheme zu sein. Naja, muss man ja nicht nutzen. Ansonsten bin ich begeistert: DVCS-Repository, gute Idee, flexible Implementierung (soll laut beschreibung auch Sandboxing unterstützen). Jetzt ist nur die Frage ob es auch funktioniert, werde das demnächst mit Mz ausprobieren.

Leonidas hat geschrieben:flexible Implementierung (soll laut beschreibung auch Sandboxing unterstützen)

Wenn ich beliebigen Code an MzScheme schicken kann, wie soll das eine Sandbox sein? Nach wie vor bin ich nicht von der Idee überzeugt, eine existierende Sprachimplementierung irgendwie per C-API an Python anzuflanschen.

Auch der Versuch, einfach genug bei CPython wegzulassen, um ein "sicheres" Sprachsubset zu bekommen, fühlt sich falsch an. Der Quelltext ist recht umfangreich und eine Garantie, dass man nichts übersieht, gibt es nicht. Ich meine gehört zu haben, dass das "härten" der Python-Version für die App-Engine Monate gedauert hat, weil die Zeile für Zeile den Quelltext gelesen und überprüft haben. Neben den offensichtlichen Problemen wie file-IO kann es ja bedingt durch die Implementationssprache C immer noch alle Arten von Buffer-Überläufen oder sonstigen Speicherfehlern kommen. Das mag vielleicht nur ein Problem für Google sein und wäre dem Poster dieses Threads hier egal, dennoch ist der Ansatz IMHO nicht empfehlenswert.

Besser finde ich daher den konstruktiven Ansatz, nur das zusammenzufügen, wo man sicher ist, dass man dadurch eine Sandbox nicht öffnet.

Stefan

sma hat geschrieben:

Leonidas hat geschrieben:flexible Implementierung (soll laut beschreibung auch Sandboxing unterstützen)

Wenn ich beliebigen Code an MzScheme schicken kann, wie soll das eine Sandbox sein?

Wer sagt denn, dass du beliebige Mz-Funktionen nutzen darfst?

Ah, du willst das Problem, eine sichere Sandbox für Python zu bauen, auf das Problem, eine sichere Sandbox für MzScheme zu bauen, verschieben? Nicht unbedingt einfacher, wenn man nicht auch diese Sprache ganz genau kennt und/oder den Autoren dort vertraut.

Stefan