EXE mit cx_Freeze erstellen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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 :!:
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

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) :roll:
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

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,
Zuletzt geändert von Francesco am Donnerstag 24. August 2006, 12:53, insgesamt 1-mal geändert.
querdenker
User
Beiträge: 424
Registriert: Montag 28. Juli 2003, 16:19
Wohnort: /dev/reality

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
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

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.
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

Habe mich auch über die Aussage von querdenker gewundert. Aber vielelicht sagt er ja noch was dazu (?).

Schneller als Assemblercode geht es doch nicht...
Francesco
User
Beiträge: 824
Registriert: Mittwoch 1. Dezember 2004, 12:35
Wohnort: Upper Austria

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.
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.
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

das ist falsch!
der pythoncode ist doch such glrich!
die python24.dll richtet alles, nur betriebssysteme, die diese dll nicht verstehen, sind davon ausgeschlossen.
http://www.cs.unm.edu/~dlchao/flake/doom/
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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
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.
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

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 ;-)
http://www.cs.unm.edu/~dlchao/flake/doom/
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

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
Antworten