Python executables?

[Aurélien Géron]

Catalin wrote:
> > How can I make executables with python?
> > I found some utilities that claim they can do something like that like
> > Installer and py2exe but they actualy pack the code in a huge arhive!
> > This solves the problem of giving python programs to users who don't
> > have python but doesn't solve the problem of the source "secrecy"
> > (copyright).
> > And the programs also run much slower and become extremely big compared
> > to a normal C++ program for example. I made a test and a 2 programs
> > doing the same thing where 400 KB with C Builder (static linked) and
> > 2.80 MB with python+installer in an arhive packed with upx and 6.9 MB
> > with py2exe(unpacked). And the speed difference was huge.
> > So can a python program become a "real" executable(I am refering both to
> > windows and unix platforms)?
> > If this is imposible with python is it possible with jpython?

Bruno wrote:
> Here you expose 3 different problems :
>
> 1/ source "secrecy" (copyright) :
> It's the wrong problem. *Any* binary code can be subject to
> reverse-engineering. There are even tools to do this quite easily for
> Java. The right way to protect your property is via copyright and licence.

IMHO, Catalin has a good point here. I'm no legal expert, but I believe that
copyrights and licences are not quite enough to protect your code. They just
mean that if someone uses your code without your authorisation, you *could*
theoretically sue them, but :
1- Would it be worth it to go and hire a lawyer and everything?
2- How would you prove it (or even know about it) if they just stole pieces
of your code? Or even algorithms?
3- Moreover, you may never know who hacked your code.  Look at all the games
and excellent software cracked everyday: do you know who dunnit? Who would
you sue?

So why not simply compile your code and make it *harder* (although not
impossible) to decypher: it'll stop most of the potential hackers.  It's
like the lock on your door: however weak it is, it'll stop most burglars
because they won't bother fighting it at all: they'll just go and look for
an unlocked house! Well... unless everyone knows there's a treasure inside
it, that is.  In which case there's not much you can do against determined
hackers except to make the task difficult for them.

I agree with Bruno about Java decompilers, though : I used them many times
and I am still amazed at the quality of the decompilation process.  In one
instance it even helped me recover my own code when all I had left was the
compiled result!  The recovered code was neatly indented and perhaps clearer
than the original code! But there are also free "obfuscators" that make your
compiled bytecode (a lot) harder to decompile.

Python bytecode has some pretty good decompilers too.

But I don't know about any decent C decompiler.  If anyone does, though, I'd
be greatly interested.


> 2/ Size of "packed" programs :
> Realize that the pack must include the whole Python interpreter and
> librairies. BTW, I personnaly never used such tools, but I think I
> remember that some of them allow you to specify which parts you really
need.

Yes, some do.

> 3/ 'Slowness' :
> I don't believe that 'packing' the program makes it slower.
>
> Are you sure your Python code is really Pythonic ? There are tips and
> tricks in how to 'optimize' Python code, and it can be very different
> from low-level (C/C++ etc) languages techniques. You may want to have a
> look at :
> http://manatee.mojam.com/~skip/python/fastpython.html
>
> Now if you really need smallest possible footprint and blazing-fast
> execution speed (which are antagonist needs anyway), and your program is
> about low-level stuff, you may not have choosen the right tool !-)

>
> Bruno
>

I don't see small footprint and fast execution speed as antagonist at all,
quite the contrary.  In fact, assembly code produces the fastest and
smallest programs.

But Bruno is right, IMHO, about choosing the right tool: if you need a 50k
program calculating Pi to the 5000th decimal in 0.1 seconds... python is
definitely *not* the way to go.

Aurélien