Compiling Python
TuxTrax
I am new to this forum, and to Python, please excuse the newbie question.
I have started reading the o'reilly book, "learning python" and find python
to be an amazing language so far. My first impression of it is a language that
is easier than basic to learn and use, and more powerful than many other
high level languages such as pascal.
My question is this; I realize that Python compiles to bytecode automatically
as part of the interpreters tokenization run, but is there a way to permanently
compile python code outputting to an executable binary?
Cheers,
Mathew
--
TuxTrax (n.) An invincible, all terrain, Linux driven armored assault
vehicle that can take as much fire as it gives ;-)
<Carnivore activation string>
ASSASINATION ANTHRAX PRESIDENT NUCLEAR TALIBAN AMMONIUM NITRATE
</Carnivore activation string>
Yes, I am a Penguin cult high priest. Fin readings upon request.
ROT13 this email address to mail me: uvtuqr...@lnubb.pbz
Jerzy Karczmarczuk
> My question is this; I realize that Python compiles to bytecode automatically
> as part of the interpreters tokenization run, but is there a way to permanently
> compile python code outputting to an executable binary?
Once upon a time Guido Van Rossum thought "this seems very difficult,
perhaps impossible".
He changed his mind a little bit now...
See:
http://www.onlamp.com/pub/a/python/2002/06/04/guido.html
and the references cited by The Master:
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
http://homepages.ulb.ac.be/~arigo/psyco/
Don't forget also that Jython produces Java code. Not an
"executable binary" directly, but ...
You may also embed a Python kernel in your application, see
the tutorial:
http://www.python.org/doc/current/ext/embedding.html
==
Jerzy Karczmarczuk
Caen, France
Michael Weiss
Look at this: (Py2Exe)
http://starship.python.net/crew/theller/py2exe/
I understand there are other options similar to py2exe that I've never
tried... like "freeze" or the stuff over at
http://www.mcmillan-inc.com/install1.html
"TuxTrax" <Tux...@fortress.tuxnet.net> wrote in message
news:slrnafrqit....@fortress.tuxnet...
Peter Hansen
>
> Hello all
>
> I am new to this forum, and to Python, please excuse the newbie question.
>
> I have started reading the o'reilly book, "learning python" and find python
> to be an amazing language so far. My first impression of it is a language that
> is easier than basic to learn and use, and more powerful than many other
> high level languages such as pascal.
>
> My question is this; I realize that Python compiles to bytecode automatically
> as part of the interpreters tokenization run, but is there a way to permanently
> compile python code outputting to an executable binary?
Why do you want to do that? For presumably increased speed, or because
you don't want the hassle of multiple .py files all over the place (in
other words, better packaging)?
-Peter
Edward K. Ream
> > My question is this; I realize that Python compiles to bytecode automatically
> > as part of the interpreters tokenization run, but is there a way to permanently
> > compile python code outputting to an executable binary?
>
> Once upon a time Guido Van Rossum thought "this seems very difficult,
> perhaps impossible".
>
> He changed his mind a little bit now...
>
> See:
>
> http://www.onlamp.com/pub/a/python/2002/06/04/guido.html
>
> and the references cited by The Master:
>
> http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
> http://homepages.ulb.ac.be/~arigo/psyco/
Thanks for these links.
Earlier this year I looked into this question in some depth and
concluded:
a) compiling Python to, say, C or C++ is in fact doable much of the
time,
b) the hard issues are more related to library compatibility (what is a
compiled object?)
c) such a project probably would be reasonable only if part of
"official" Python.
As far as a) goes, it should be possible to "propagate" type information
from constants and arguments and return values from known library
routines, so that in fact a lot more type information may be present
than one might think. I saw this first this way: there is an
isomorphism between the C++ and Python versions of Leo, so it ought to
be possible to back translate from leo.py to leo.cpp. The more I looked
at this, the more plausible it became. However, because of b), it is
not clear what kind of performance improvements can be expected. Point
b) also implies a close connection between compiler, interpreter and
libraries, which is why I say c).
I offer the following existence proof for the possibility of compiling
Python. One could simply "unwrap" the Python interpreter. That is, we
could replace byte codes with the equivalent portions of the
interpreter's main loop. Obviously, nothing practical is gained by
this. However, it does provide a mental picture of what is going on,
and it hints at what might need to be optimized in order to make a
compiler practical.
I found this preliminary design work to be great fun, and I am excited
that Guido has shown some interest in this area. I wonder whether there
would be any interest in a sig related to this subject? I have lots of
experience and ideas on this subject and I would love to toss ideas
around.
BTW, a compiled version of a Python program would be valuable
commercially, as it would allow companies to protect their source code,
as well as (possibly) improve performance.
If anyone knows of any reasons why a Python to C++ compiler clearly can
not be made to work, I would be very interested in hearing them.
Edward
--------------------------------------------------------------------
Edward K. Ream email: edr...@tds.net
Leo: Literate Editor with Outlines
Leo: http://personalpages.tds.net/~edream/front.html
--------------------------------------------------------------------
TuxTrax
Hi Peter
I was more interested in if there were existing tools to do it, already
available.
I really don't care to "hide" my source code, as I hail from the open source
Linux community (kind of like "I'm from star fleet, I never lie" <g>)
and I would be releasing any source for any python app that I wrote (that was
any good <g>) anyway. Besides, if you know others will be seeing your source
you tend to write cleaner code <g>.
As I noted, it was a newbie question, a matter of curiousity. I am just
starting to learn python and I really love it, and I am full of such
questions that probably others have already gotten past.
Packaging is a thought, but speed (so far) isn't an issue, as python is pretty
fast IMHO.
Graham Ashton
> My question is this; I realize that Python compiles to bytecode
> automatically as part of the interpreters tokenization run, but is there
> a way to permanently compile python code outputting to an executable
> binary?
Not exactly, in general. Have a look for py2exe, psyco, and pyrex for info
on some of the things that you can currently do.
GvR alludes to compilation being of interest in the future in a recent
interview:
http://www.onlamp.com/pub/a/python/2002/06/04/guido.html
--
Graham Ashton
Peter Hansen
>
> On Wed, 05 Jun 2002 10:44:43 -0400, Peter Hansen <pe...@engcorp.com> wrote:
> > TuxTrax wrote:
> >> My question is this; I realize that Python compiles to bytecode automatically
> >> as part of the interpreters tokenization run, but is there a way to permanently
> >> compile python code outputting to an executable binary?
> >
> > Why do you want to do that? For presumably increased speed, or because
> > you don't want the hassle of multiple .py files all over the place (in
> > other words, better packaging)?
> Packaging is a thought, but speed (so far) isn't an issue, as python is pretty
> fast IMHO.
Okay, no probs. I was concerned that you might have wanted a speedup,
and with the answers like "py2exe" you would not see that speedup
because all they really do is bundle everything together with
"frozen" bytecode and a copy of the interpreter...
-Peter
TuxTrax
Thanks for the information, Graham.
Kragen Sitaker
> BTW, a compiled version of a Python program would be valuable
> commercially, as it would allow companies to protect their source code,
> as well as (possibly) improve performance.
I'm worried about this myself; perhaps the compiler could include the
source code in the resulting executable to prevent this.
Edward K. Ream
> > http://homepages.ulb.ac.be/~arigo/psyco/
>
> Thanks for these links.
>
> Earlier this year I looked into this question in some depth and
> concluded:[snip]
Never mind. It looks like the psyco project is where the action is.
Jeff Epler
Your sarcasm is lost on me.
Jeff
Steve Holden
Lost, perhaps, but (since you recognised it) not entirely wasted ;-)
regards
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------
Don Garrett
It's a packaging issue for me. It's worth a lot to be able to just ship a
program to a customer without their needing to understand that I wrote it in
Python (thanks py2exe!). A fact about which they usually don't care. I also
don't have to explain to them how to download/install the Python runtime.
It's also useful since the runtime matches the version of python I
developed with, and they never have to go update the python runtimes on all
the machines to which they have deployed.
It would be even more useful if there was an easy way to produce a
standalone RPM or MSI file (depending on the plateform). The MSI file is
probably more useful. The unix people are more capable of dealing with the
extra steps of getting a python program to work.
David Bolen
> It would be even more useful if there was an easy way to produce a
> standalone RPM or MSI file (depending on the plateform). The MSI file is
> probably more useful. The unix people are more capable of dealing with the
> extra steps of getting a python program to work.
While not MSI, there are free setup programs (I'm a fan of InnoSetup)
that will produce a perfectly standard looking Windows installation
executable for your application. You can couple that with the
installer/py2exe output to look like a standard Windows setup.
If you're already doing this and just specifically want an MSI format,
then ignore the point. :-)
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Kragen Sitaker
> "Jeff Epler" <jep...@unpythonic.net> wrote ...
> > On Thu, Jun 06, 2002 at 12:58:59PM -0400, Kragen Sitaker wrote:
> > > "Edward K. Ream" <edr...@tds.net> writes:
> > > > BTW, a compiled version of a Python program would be valuable
> > > > commercially, as it would allow companies to protect their source
> code,
> > > > as well as (possibly) improve performance.
> > >
> > > I'm worried about this myself; perhaps the compiler could include the
> > > source code in the resulting executable to prevent this.
> >
> > Your sarcasm is lost on me.
>
> Lost, perhaps, but (since you recognised it) not entirely wasted ;-)
I don't know why you thought I was being sarcastic. I was completely
serious.
The Java guys have probably a better solution: don't save the compiled
code to disk. A traditional compiler that included the source code in
the executable (like, approximately, javac) could easily be hacked to
remove the source code; but turning a JIT compiler into a traditional
compiler is a bit more work.
Don Garrett
> While not MSI, there are free setup programs (I'm a fan of InnoSetup)
> that will produce a perfectly standard looking Windows installation
> executable for your application. You can couple that with the
> installer/py2exe output to look like a standard Windows setup.
>
> If you're already doing this and just specifically want an MSI format,
> then ignore the point. :-)
I haven't been using anything like that, but was planning to start shortly.
I was just hoping to have py2exe (or someone) output MSI to make it a single
idiot proof step. And sometimes I can make for a pretty good idiot.
--
Don Garrett http://www.bgb.cc/garrett/
BGB Consulting gar...@bgb.cc