Python 2.5.1 startet nicht unter Vista32bit

[Leonidas]

Wenn dein Python-Programm mit Leerzeichen klar kommt, gibt es auch mit dem ge-freezten Programm keine Probleme. Warum auch.

[BlackJack]

Na weil auch ein ge"freeze"tes Tcl nicht plötzlich auf magische Weise Leerzeichen in Pfaden mag!?

[Leonidas]

Na weil auch ein ge"freeze"tes Tcl nicht plötzlich auf magische Weise Leerzeichen in Pfaden mag!?

Und wo habe ich das behauptet?

Wenn dein Python-Programm mit Leerzeichen klar kommt

Wenn es wegen Tkinter crasht dann kommt es logischerweise nicht mit Leerzeichen klar. Daran ändert das freezen ja nichts.

[BlackJack]

Du hast es nicht explizit behauptet, aber im Kontext, dass es hier in den letzten Beiträgen darum ging, ob man Tkinter wegen Vista nicht benutzen sollte und ob man mit einem ge"freeze"ten Programm "sicher" ist, könnte man das da rauslesen.

[Erwin]

Wenn es wegen Tkinter crasht dann kommt es logischerweise nicht mit Leerzeichen klar. Daran ändert das freezen ja nichts.

Darum geht es mir ja.
Soll das jetzt heißen, da dies nun mal unter Vista crasht, dass dies mit dem gefreeztem Programm dann genau so passiert?
Also die exe-Erstellung nichts daran ändert?
Dass halt leider auch der Teil der exe, der für die GUI dann zuständig ist, nicht mit Leerzeichen klar kommt?
Eben weil diese genau so wie das ursprüngliche Tcl selbst in exe verpackt keine Leerzeichen verkraftet?

[Leonidas]

aber im Kontext, dass es hier in den letzten Beiträgen darum ging, ob man Tkinter wegen Vista nicht benutzen sollte und ob man mit einem ge"freeze"ten Programm "sicher" ist, könnte man das da rauslesen.

Echt? Naja, jedenfalls habe ich das so nicht gemeint.

Also nochmal zur Klarstellung: Wenn ein Python-Programm mit Leerzeichen im Pfad klarkommt, dann funktioniert ein gefreeztes Programm auch. Wenn es das nicht tut, weil was auch immer kaputt ist (ob das nun Tkinter ist oder etwas anderes), dann funktioniert eine gefreezre Version auch nicht. Das freezen hat auch die Leerzeichenbehandlung gar keinen Einfluss da Tools wie py2exe ja nur den Python-Interpreter und einige Libs in eine EXE packen und sich sonst nichts ändert.

[Erwin]

Also nochmal zur Klarstellung: Wenn ein Python-Programm mit Leerzeichen im Pfad klarkommt, dann funktioniert ein gefreeztes Programm auch. Wenn es das nicht tut, weil was auch immer kaputt ist (ob das nun Tkinter ist oder etwas anderes), dann funktioniert eine gefreezre Version auch nicht. Das freezen hat auch die Leerzeichenbehandlung gar keinen Einfluss da Tools wie py2exe ja nur den Python-Interpreter und einige Libs in eine EXE packen und sich sonst nichts ändert.

Oha.
Bedeutet dass dann auch, dass man bei einem gefreeztem Programm (welches Tcl als GUI nutzt) Tcl mitschicken müsste, falls der Anwender es nicht bereits installiert hat?

[Leonidas]

Bedeutet dass dann auch, dass man bei einem gefreeztem Programm (welches Tcl als GUI nutzt) Tcl mitschicken müsste, falls der Anwender es nicht bereits installiert hat?

Ja, man braucht eben alles was zur Ausführung nötig ist. Aber py2exe kümmert sich schon darum, alles nötige beizupacken. Wird dann nur eben recht groß.

[Erwin]

Ja, man braucht eben alles was zur Ausführung nötig ist. Aber py2exe kümmert sich schon darum, alles nötige beizupacken. Wird dann nur eben recht groß.

Und dann wird es auf den Windows ausgepackt?
Aber leider halt nach den Regeln, wie es sonst auch (also Tcl allein) ausgepackt wird?
Somit funktioniert es dann wohl genau so, als wenn man es extern/extra installiert hätte?
Tja, dann ist es vollkommen logisch, dass dann Tcl auch nach dem freezem Ärger macht.
Dann müsste man in dem Fall den Benutzer also anweisen, er soll den Tcl-Teil in Ordner installieren, die kein Leer enthalten?
Das will mir alles nicht gefallen.

[Leonidas]

Somit funktioniert es dann wohl genau so, als wenn man es extern/extra installiert hätte?

Natürlich. Der Vorgang heißt ja "freezen" und nicht "bugfixen"

Dann müsste man in dem Fall den Benutzer also anweisen, er soll den Tcl-Teil in Ordner installieren, die kein Leer enthalten?
Das will mir alles nicht gefallen.

Dann warte entweder auf eine korrigierte Version, korrigiere es selbst oder steige auf ein Toolkit aus diesem Jahrzehnt um

[Erwin]

Dann warte entweder auf eine korrigierte Version, korrigiere es selbst oder steige auf ein Toolkit aus diesem Jahrzehnt um

Wird es eine korrigierte geben?
Selbst traue ich mir das nicht zu.
aus diesem Jahrzehnt? Du meinst jetzt wohl wxPython?
Nur bei meinen miesen Englisch ... .
Selbst über Tkinter scheint es nur das an Lektüre zu geben, was nebenbei in den Büchern zu Python dazu steht.
Dabei fällt mir ein, ich müsste mir wxPython ja erst mal auf meine Festplatte installiere.

[Leonidas]

Dann warte entweder auf eine korrigierte Version, korrigiere es selbst oder steige auf ein Toolkit aus diesem Jahrzehnt um

Wird es eine korrigierte geben?

Würde mich wundern wenn nicht. Andernfalls wird der Windows-Port ja auf allen Vista-Rechnern kaputt sein. Da könnte man den Windows-Port dann auch ganz abschaffen.

aus diesem Jahrzehnt? Du meinst jetzt wohl wxPython?

wxPython, PyGTK, PyQt.

[gerold]

Hallo!

Die Lösung ist doch so einfach. Unter Windows -- Python in den Standardordner installieren und fertig.

Tkinter wird so schnell nicht aussterben -- auch wenn ich mir wxPython als Standard-GUI-Toolkit wünschen würde -- und in der nächsten Python-Version wird es dieses Problem wahrscheinlich schon nicht mehr geben. Bitte macht doch aus einer Kuh keinen Erdrutsch.

mfg
Gerold

[Erwin]

Würde mich wundern wenn nicht. Andernfalls wird der Windows-Port ja auf allen Vista-Rechnern kaputt sein. Da könnte man den Windows-Port dann auch ganz abschaffen.

Vista gibt es aber schon seit fast einem Jahr.

Die Lösung ist doch so einfach. Unter Windows -- Python in den Standardordner installieren und fertig.

Ob das einem verwöhnten Windows-Anwender gefällt?
Aber ich mache mir wie Üblich wirklich zu viele Negative Gedanken.

[Leonidas]

Würde mich wundern wenn nicht. Andernfalls wird der Windows-Port ja auf allen Vista-Rechnern kaputt sein. Da könnte man den Windows-Port dann auch ganz abschaffen.

Vista gibt es aber schon seit fast einem Jahr.

Python 2.5 sogar schon länger.

[Erwin]

Würde mich wundern wenn nicht. Andernfalls wird der Windows-Port ja auf allen Vista-Rechnern kaputt sein. Da könnte man den Windows-Port dann auch ganz abschaffen.

Vista gibt es aber schon seit fast einem Jahr.

Python 2.5 sogar schon länger.

?
Achso?
Du meinst, dass vielleicht bei einer neueren Pythonversion das Tcl-Problem bereits bereits behoben ist?

[Leonidas]

Würde mich wundern wenn nicht. Andernfalls wird der Windows-Port ja auf allen Vista-Rechnern kaputt sein. Da könnte man den Windows-Port dann auch ganz abschaffen.

Vista gibt es aber schon seit fast einem Jahr.

Python 2.5 sogar schon länger.

Achso?
Du meinst, dass vielleicht bei einer neueren Pythonversion das Tcl-Problem bereits bereits behoben ist?

Nein - zumindest nicht direkt. Ich wollte nur sagen, dass Python sich kaum auf Vista-Probleme einstellen kann, wenn es älter als Vista selbst ist. Und eigentlich kann Python selbst kaum was für Tcl-Bugs.

Natürlich hat die Argumentation einige Schwachstellen, da es in englischsprachigen Windows-Versionen seit Windows 95 schon "Program Files" hieß. Also hatten die Tcl-Leute schon genug Zeit das hinzubekommen. Keine Ahnung, warum das nach so vielen Jahren immer noch ein Problem ist. Vielleicht nutzt das sowieso niemand unter Windows.