Python Compiller

Du hast eine Idee für ein Projekt?
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

lunar hat geschrieben:
DasIch hat geschrieben:Das kann man sich alles aber auch denken wenn man sich Python anschaut. Ein Compiler wird zwangsläufig eine recht aufwendige Runtime generieren müssen und einige Sprach Features wie AST/Bytecode Manipulation, eval/exec sind einfach mit einem Compiler nicht realisierbar.
Warum? Diese Features gibt es in diversen „kompilierten“ Sprache, u.a. Java und C# (generell .NET), bei letzterem sogar als integraler Bestandteil der Sprache (siehe Expression Trees).
Nachdem Java und C# dann "kompiliert" sind werden sie von eine VM ausgeführt wie bei CPython oder PyPy auch.
Sirius3
User
Beiträge: 17747
Registriert: Sonntag 21. Oktober 2012, 17:20

also auf den Punkt gebracht:
Was den Dummy-Windows-User stört, ist, dass Python nicht so schön tief im Betriebssystem
verankert ist, wie .NET.

Bei .NET steckt in der EXE alles drin was der Interpreter zum Interpretieren braucht.
Schön versteckt. Dass in der Datei kein Maschinencode drinsteckt, merkt man von
außen gar nicht.

Und wie man in java in einer einzigen .jar-Datei eine ganze Application packen und ausführen kann,
geht das mit python und einer entsprechenden .zip-Datei auch.
Notfalls baut man für jede Pythonversion eine eigene zip mit nur den pyc-Dateien, dann hat man
seine »kompilierte« Version mit all ihren Nachteilen.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Sirius3 hat geschrieben: Bei .NET steckt in der EXE alles drin was der Interpreter zum Interpretieren braucht.
Schön versteckt.
Naja, ohne installierte Runtime läuft eine exe, in der Programme auf .NET-Basis stecken, auch nicht. Ok, in den Versionen nach XP ist .NET-Framework vermutlich per default installiert und daher in der Praxis kein Hemmschuh mehr.

Prinzipiell wäre das aber auch mit Python kein Problem. Man könnte eine Art Standard-Template mit WiX bauen, welches auf das Vorhandensein von Python prüft und darüber hinaus ggf. auch PATH anpasst. Dann hätte man einen EXE-Installer, der zur Not alle Voraussetzungen nachinstalliert. Will man sein Programm veröffentlichen, so muss man nur ein MSI bauen, welches die zu installierenden Dateien enthält und den Installer neu erstellen. Gehen täte das auch - nur macht sich wohl eher keiner den Aufwand ;-)
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
microkernel
User
Beiträge: 271
Registriert: Mittwoch 10. Juni 2009, 17:27
Wohnort: Frankfurt
Kontaktdaten:

Aber ist der Python Interpreter nicht in C geschrieben? Warum ist es dann nicht möglich den Python-Code in C-Code zu embedden, die python lib zu inkludieren und dann das gesamte programm mit einem c-compiler zu kompilieren? Sorry, wenn ich jetzt vielleicht doof frage, oder so...
Benutzeravatar
cofi
Python-Forum Veteran
Beiträge: 4432
Registriert: Sonntag 30. März 2008, 04:16
Wohnort: RGFybXN0YWR0

In deiner Beschreibung fehlt das Python-Programm und genau da liegt das Problem. Python selbst einzubinden ist kein Problem, Dokumentation dazu gibt es direkt in der Python-Dokumentation und es wird oft gemacht.
lunar

Hyperion hat geschrieben:
Sirius3 hat geschrieben: Bei .NET steckt in der EXE alles drin was der Interpreter zum Interpretieren braucht.
Schön versteckt.
Naja, ohne installierte Runtime läuft eine exe, in der Programme auf .NET-Basis stecken, auch nicht.
Kein Programm läuft ohne Laufzeitumgebung, auch ein in Maschinensprache übersetztes C- oder C++-Programm nicht. Wer jemals C++-Anwendungen unter Windows verteilt hat oder alte Linux-Programme mit neueren C++-Standardbibliotheken ausführen wollte, weiß wovon ich spreche.

Das Problem bei Python ist nicht, dass man die Laufzeitumgebung installieren müsste, sondern dass eben das unter WIndows nicht einfach ist. Zudem ist das Deployment von Python-Anwendungen unter Windows auch nicht einfach, da CPython keine Werkzeuge bietet, um eine Anwendung samt ihrer Abhängigkeiten in ein in sich abgeschlossenes „Paket“ zu verwandeln.

Ich sehe auch nicht, dass sich dieses Problem irgendwann nicht mehr stellt, denn Windows-Deployment scheint – vorsichtig formuliert – keine Priorität der Python-Entwickler zu sein.
Benutzeravatar
vegaseat
User
Beiträge: 6
Registriert: Montag 28. Januar 2013, 22:53
Wohnort: Las Vegas Nevada USA

Schau Dir mal Ironpython an, das hat so ziemlich alles. Ironpython 2.7.3 ist Python 2.7.3 und mehr. Es arbeited mit Windows .NET (CLR) oder Linux Mono fuer GUI Programme. Du kannst es 'interpretieren' mit ipy.exe oder 'compilieren' mit dem Program pyc.py (beigelegt) zu einem .exe und .dll (recht klein).

Hier is ein einfaches GUI Beispiel, hoffentlich ist Dein Englisch einigermassen gut ...

Code: Alles auswählen

''' ip_button2.py
Create a window with 2 buttons using Ironpython
experiment with events, colors, styles

Ironpython gives access to the Windows .NET or Linux Mono libraries

Download ironpython from:
http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12481

Tutorial at:
http://www.zetcode.com/tutorials/ironpythontutorial/

If ironpython is installed in 'C:\IronPython27\'
and you save this script as 'ip_Buttons2.py' in subdirectory 'Atest'
then you can run it (interpreter) with command:
C:\IronPython27\ipy.exe C:\IronPython27\Atest\ip_Buttons2.py

I have the Editra IDE set to run Ironpython directly.

The SharpDevelop4 IDE allows you to use Ironpython code and design forms
drag and drop style similar to MS Studio.

You can also compile it to a ip_button2.exe and ip_button2.dll
with utility program pyc.py.  Use this batch file ...
C:/IronPython27/ipy.exe C:/IronPython27/Tools/Scripts/pyc.py /main:ip_button2.py /target:winexe

Tested with Ironpython 2.7.3  by  vegaseat  28jan2013
'''

import clr

clr.AddReference("System.Windows.Forms")
clr.AddReference("System.Drawing")

from System.Windows.Forms import Application, Form, Button
from System.Windows.Forms import FlatStyle
from System.Drawing import Size, Point, Color

class IForm(Form):

    def __init__(self):
        # set form title, position, size, bachground color
        self.Text = 'Button and Color'
        # center the form on the screen
        self.CenterToScreen()
        self.Size = Size(300, 150)
        self.BackColor = Color.Green

        btn1 = Button()
        btn1.Parent = self
        btn1.Text = "Quit"
        btn1.Location = Point(50, 30)
        btn1.BackColor = Color.Pink
        # click on the button to call btn1_OnClick()
        btn1.Click += self.btn1_OnClick

        btn2 = Button()
        btn2.Parent = self
        btn2.Text = "Press Me"
        btn2.Location = Point(50, 70)
        btn2.FlatStyle = FlatStyle.Popup
        btn2.BackColor = Color.Linen
        # click on the button to call btn2_OnClick()
        btn2.Click += self.btn2_OnClick

    def btn1_OnClick(self, sender, args):
        self.Close()
        # test information ...
        print(sender)            # System.Windows.Forms.Button, Text: Quit 
        print(sender.BackColor)  # Color [Pink]       

    def btn2_OnClick(self, sender, args):
        self.Text = 'btn2 pressed'
        # test information ...
        print(sender)
        print(sender.Text, type(sender.Text))


Application.Run(IForm())
Info:
ip_button2.exe (3kB)
ip_button2.dll (12kB)
BlackJack

@vegaseat: Jetzt vergleiche mal die Grösse von EXE und DLL mit den *.pyc-Dateien die CPython erzeugt. Und man braucht ja bei IronPython trotzdem noch IronPython selbst *und* .NET um es laufen zu lassen. Addiere mal *die* Grössen auf und vergleiche sie mit der Laufzeitumgebung von CPython.

Was gewinnt man denn durch die Kompilierung in EXE und DLL? Ausser das fragwürdige „jetzt habe ich aber eine EXE!!1!elf!!”.
Antworten