Seite 1 von 2
Verfasst: Donnerstag 24. August 2006, 02:58
von JR
Hi Gerold,
ich habe ein einfaches Script namens MAIN.py erstellt:
Code: Alles auswählen
import sys
def main():
"""
Dieses Script kann aus der Pythonshell \x81ber
os.system('hallo.py') oder
os.system('hallo.py zahl1 zahl2') gerufen werden.
"""
if len(sys.argv) > 1:
zahl1 = int(sys.argv[1])
zahl2 = int(sys.argv[2])
else:
zahl1 = int(raw_input('Geben Sie bitte Zahl 1 ein!\n'))
zahl2 = int(raw_input('Geben Sie bitte Zahl 2 ein!\n'))
print('Die Summe ist: %d' %(zahl1 + zahl2))
#Rueckgabewert an aufrufendes Programm:
sys.exit(0)
if __name__ == '__main__':
main()
Dieses Script übersetzte ich mit cx_Freeze über folgendes Script (compile.py):
Code: Alles auswählen
#compile.py
import os
def main():
PYTHONFILE = raw_input('\nGeben Sie den Namen (ohne .py) des Scripts ein:\n')
PYTHONFILE = PYTHONFILE + '.py'
os.system('FreezePython.exe --install-dir=dist\win --base-name=Win32GUI.exe %s'%(PYTHONFILE))
if __name__ == '__main__':
main()
Das Übersetzen klappte, doch die Anwendung MAIN.exe liefert mir sofort eine Fehlermeldung:
Type: exceptions.ImportError
Value: No module named traceback
Other Type: exceptions.EOFError
Other Value: EOF when reading a line
Cannot import traceback module
Als ich dasselbe Script mit py2exe übersetzen lief, klappte aber alles und ich konnte meine MAIN.exe mit oder ohne Argumenten aus der Shell heraus verwenden.
Weißt du, woran das liegt? EOF = End Of File, doch was spielt das hier für eine Rolle?
Viele Grüße
Jamil
Nachtrag
Verfasst: Donnerstag 24. August 2006, 03:02
von JR
cx_Freeze wäre mir lieber, da es nur zwei dateien anlegt.
MAIN.exe und python24.dll (2,06 MB)
py2exe erstellt aber insgesamt 8 Dateien mit 3,27 MB
Naja, viellicht hast du ja eine Idee!? Jetzt gehöre ich aber schon seit 5 Stunden ins Bett

Verfasst: Donnerstag 24. August 2006, 08:32
von gerold
Hi Jamil!
Du hast cx_Freeze mitgeteilt, dass du eine WindowsGUI-Anwendung machen möchtest. --> ``--base-name=Win32GUI.exe``. Stattdessen musst du cx_Freeze Bescheid geben, dass du eine Konsolen-Anwendung erstellen möchtest. --> ``--base-name=Console.exe``
Hier das Ausgebesserte Beispiel:
summe.py:
Code: Alles auswählen
#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-
import sys
def main():
"""
Dieses Script kann aus der Pythonshell über
os.system('hallo.py') oder
os.system('hallo.py zahl1 zahl2') gerufen werden.
"""
if len(sys.argv) > 1:
zahl1 = int(sys.argv[1])
zahl2 = int(sys.argv[2])
else:
zahl1 = int(raw_input('Geben Sie bitte Zahl 1 ein!\n'))
zahl2 = int(raw_input('Geben Sie bitte Zahl 2 ein!\n'))
print('Die Summe ist: %d' %(zahl1 + zahl2))
return True
if __name__ == '__main__':
#Rueckgabewert an aufrufendes Programm:
if main():
sys.exit(0)
else:
sys.exit(1)
make_exe_win.cmd:
Code: Alles auswählen
REM --------------------------------------------------
REM Erstellt aus dem PYTHONFILE eine ausführbare EXE
REM --------------------------------------------------
SET PROJECTDIR="J:\Dokumente und Einstellungen\Gerold\Desktop\JR"
SET PYTHONFILE="summe.py"
CD /D %PROJECTDIR%
RD /S /Q dist
MD dist
MD dist\win
COPY %SystemRoot%\system32\msvcr71.dll dist\win\
FreezePython.exe --install-dir=dist\win --base-name=Console.exe %PYTHONFILE%
PAUSE
Der Pfad zum %PROJECTDIR% muss natürlich angepasst werden.
lg
Gerold

Re: Nachtrag
Verfasst: Donnerstag 24. August 2006, 09:06
von jens
JR hat geschrieben:cx_Freeze wäre mir lieber, da es nur zwei dateien anlegt.
...
py2exe erstellt aber insgesamt 8 Dateien mit 3,27 MB
ich dachte das py2exe in den neueren Version auch nur eine Datei backen kann...
Verfasst: Donnerstag 24. August 2006, 12:26
von JR
Hi Gerold, so schauts nun aus:
compile.py:
Code: Alles auswählen
#compile.py
import os, string
def main():
PYTHONFILE = raw_input('\nGeben Sie den Namen (ohne .py) des Scripts ein:\n')
if not PYTHONFILE.endswith('.py'):
PYTHONFILE = PYTHONFILE + '.py'
PYTHONFILEWITHPATH = os.getcwd() + '\\' + PYTHONFILE
raw_input(PYTHONFILEWITHPATH + '\n')
if os.path.isfile(PYTHONFILEWITHPATH):
if raw_input('\nHandelt es sich um eine GUI-Anwendung (j = ja)?\n\n') == 'j':
base_name = 'Win32GUI.exe'
else:
base_name = 'Console.exe'
try:
os.system('FreezePython.exe --install-dir=dist\win --base-name=%s %s'%(base_name, PYTHONFILE))
except:
print 'Beim Ausf\x81hren von FreezePython ist ein Fehler aufgetreten.'
else:
print 'Die Datei %s konnte nicht gefunden werden.'%PYTHONFILEWITHPATH
if __name__ == '__main__':
main()
Vielen Dank
Grüße
Jamil
Verfasst: Donnerstag 24. August 2006, 12:33
von Francesco
Hi,
Was ich oft nicht verstehe, ist die übertriebene Fixierung, eine "exe" daraus zu machen. Ist es erst dann ein "richtiges, gescheites" Programm?
Gewöhnt an C/C++? Fühlt man sich dann sicherer? Ich glaube das ist mehr ein psychologisches Phänomen.
Python ist eine Skriptsprache und ich würde nie eine exe machen.
Für jede exe müssen zig MB runtergeladen werden und das Python script hat vielleicht einige kB's.
Einem möglichen user auffordern, Python und/oder wxPython einmal zu installieren, sollte doch nicht zu schwer sein (frage ich mich)

Verfasst: Donnerstag 24. August 2006, 12:36
von JR
Wenn es nach mir ginge, würde wir auf Arbeit voll auf Python umstellen, doch dann wären einige Tausend Stunden Umbau nötig und meine Kollegen müssten sich in Python einarbeiten.
Ist doch nicht schlimm, wenn man eine *.exe-Anwendung schick findet, oder?
Ach ja, eines weiß ich nicht sicher:
Ist eine *.exe nicht schneller als *.py bzw. der Bytecode?
Gruß
JR
Verfasst: Donnerstag 24. August 2006, 12:48
von Francesco
JR hat geschrieben:Wenn es nach mir ginge, würde wir auf Arbeit voll auf Python umstellen, doch dann wären einige Tausend Stunden Umbau nötig und meine Kollegen müssten sich in Python einarbeiten.
Ist doch nicht schlimm, wenn man eine *.exe-Anwendung schick findet, oder?
War ja nur ein lauter Gedanke, jetzt nicht speziell auf diesen Thread bezogen. Andererseits eine Verknüpfung (in windows) mit pythonw.exe sollte einem User auch nicht allzuschwerfallen.
In dem Project DrPython habe ich das auch einmal versucht.
Der Nachteil ist, dass dann die Plugins (zur Laufzeit geladen) nicht mehr funktionieren. Ich persönlich hasse es einfach (Traceback in Datei umleiten, ist ein Fehler, gestaltet sich die Suche aufwendiger, ...)
JR hat geschrieben:Ach ja, eines weiß ich nicht sicher:
Ist eine *.exe nicht schneller als *.py bzw. der Bytecode?
Gruß
JR
Hab gehört, das es nicht die Welt aber um eine Spur schneller sei.
Nachtrag: Fairerweise möchte ich zugeben, dass man andererseits Fehler wieder schneller finden kann und insoweit auf mehr Stabilität setzen kann, da das ganze "eingeschweist" ist, d.h. das Python 2.4.x wurd z.B. mit wxPython 2.6.0.1 Ansi ausgeliefert.
Sonst gestaltet sich die Frage dann. Bei mir hats funktioniert; komisch, dann kommt man drauf, dass eine andere Version neuer/oder älter inkompatibel oder buggy ist. (ältere WxPython Version, bei dir nicht; ach ja, ich habe ansi und du unicode)
Das könnte ein Argument sein.
cu,
Verfasst: Donnerstag 24. August 2006, 12:49
von querdenker
Nein, eine .exe ist nicht schneller. Sie kann es gar nicht sein, da sie nichts anderes ist als der Interpreter und die Bytecode-Files
mfg, querdenker
Verfasst: Donnerstag 24. August 2006, 12:52
von JR
Hi!
Es ist also so, dass die aus einer *.py-Datei erstellten *.exe oder *.pyc-Dateien beide klaren Maschinencode (also nur Nullen und Einsen - unterste Ebene) enthalten?
Greetings
JR
Verfasst: Donnerstag 24. August 2006, 12:54
von Francesco
JR hat geschrieben:Hi!
Es ist also so, dass die aus einer *.py-Datei erstellten *.exe oder *.pyc-Dateien beide klaren Maschinencode (also nur Nullen und Einsen - unterste Ebene) enthalten?
Greetings
JR
Nein, pyc ist kein Assembler bzw. Maschinencode.
Verfasst: Donnerstag 24. August 2006, 12:55
von JR
Habe mich auch über die Aussage von querdenker gewundert. Aber vielelicht sagt er ja noch was dazu (?).
Schneller als Assemblercode geht es doch nicht...
Verfasst: Donnerstag 24. August 2006, 12:56
von Francesco
querdenker hat geschrieben:Nein, eine .exe ist nicht schneller. Sie kann es gar nicht sein, da sie nichts anderes ist als der Interpreter und die Bytecode-Files
mfg, querdenker
Ahm, da würde ich nicht darauf wetten, da das Programm nicht mehr zur Laufzeit interpretiert wird. Lasse mich aber gerne eines besseren belehren.
Verfasst: Donnerstag 24. August 2006, 14:03
von BlackJack
Eine EXE enthält den Interpretierer und alle Python-Dateien. Wenn man die startet, dann wird das alles irgendwo hin-entpackt und ganz normal gestartet. Dürfte also langsamer sein weil zusätzliche Arbeit geleistet werden muss.
Und *.pyc Dateien enthalten Bytecode für den Interpretierer und keinen Maschinencode für den Prozessor.
Verfasst: Donnerstag 24. August 2006, 14:17
von JR
Hi BalckJack,
davon, dass die *.pyc für den Interpretierer sind, bin ich ausgegangen.
Man kann also zusammenfassen:
Es ist derzeit ÜBERHAUPT NICHT möglich, mit Python aus einer einfachen helloworld.py eine eigenständige helloworld.exe zu machen, welche auf den Betriebssystemen läuft, die dem Betriebssystem entsprechen, auf welchem kompiliert wurde!?
Gruß
JR
Verfasst: Freitag 25. August 2006, 21:56
von murph
das ist falsch!
der pythoncode ist doch such glrich!
die python24.dll richtet alles, nur betriebssysteme, die diese dll nicht verstehen, sind davon ausgeschlossen.
Verfasst: Freitag 25. August 2006, 22:17
von JR
Also ist es richtig. Ich meinte, dass es nicht möglich ist, eine EIGENSTÄNDIGE helloworld.exe kompilieren, wie es z.B. in C möglich ist. Man benötigt bei Python mind. die python.dll.
Also bis denn
JR
Verfasst: Freitag 25. August 2006, 22:22
von BlackJack
Definiere "wie in C möglich". Auch bei C brauchst Du im Normalfall die Laufzeitbibliothek die zum Compiler passt.
Und bei py2exe & Co wird der Python-Interpretierer mitgeliefert, verhält sich also so ähnlich wie eine statisch gebundene Laufzeitbibliothek bei C.
Verfasst: Freitag 25. August 2006, 22:24
von murph
also der code wird eigentlich immer noch immer als pyc weitergereicht, welches universell ist.
[quote = JR], welche auf den Betriebssystemen läuft, die dem Betriebssystem entsprechen, auf welchem kompiliert wurde!? [/quote]#
der anhang hat mir zu schaffen gemacht, ob du da den überblick hast

Verfasst: Freitag 25. August 2006, 22:26
von JR
Hi!
Wenn ich eine *.exe erstelle und betriebssystemspezifische Module einbinde, dann funktioniert das Kompilieren ansich nur auf dem entsprechenden OS und das Auführen der Anwendung ist ebenfalls OS-gebunden. Falsch?
Grüße und elider Gute Nacht, schaue morgen wieder rein.
Grüße
JR