[Python-il] Fwd: Perl Vs. Python on Various Points

Shlomi Fish shlomif at iglu.org.il
Wed Jul 22 12:53:40 IDT 2009

On Wednesday 15 July 2009 12:47:58 Beni Cherniavsky wrote:
> On Mon, Jul 13, 2009 at 16:19, Roman Gaufman<hackeron at gmail.com> wrote:
> > I didn't tell my "clients" anything - my employer said you can't use
> > Perl because it doesn't have compiled bytecode, I asked what about
> > python, it does -  they came back to me saying to use it.
> If you are satisfied with this outcome, more power to you ;-)
> If want ammunition in favor of Perl:
> 1. Python bytecode is really easy to decompile, waaay easier than C.
>   Details below.
>   Be careful with stressing this, lest your employer demands C :-\
> 2. Perl also uses bytecode, it just doesn't spew it into files by default.
>   But it's easy to do - see below.

Hi Beni!

Just wanted to thank you for this great post of yours. You've confirmed my 


	Shlomi Fish

> > There are disassemblers and decompilers for just about all compiled
> > bytecode out there - they show you the virtual machine instructions
> > used and some reference identifiers. There are also disassemblers and
> > decompilers for compiled C code, that also show you the machine
> > instructions being used.
> Bytecodes tend to use higher-level operations, with well-defined
> function frames on stack, debug information, and no ugly C-style
> optimizations (inlining, unrolling, order-changing scheduling, etc.)
> Also, dynamic languages like Python have almost no information
> that can be thrown out after compilation (e.g. types).  Everything
> you write is needed for running.
> > pyc is compiled bytecode - so while you can reverse engineer compiled
> > bytecode (as you can reverse engineer just about everything) -- you
> > don't have nesting depths, scope, type - all you have is numeric
> > codes, numeric addresses and some visible references. It's a little
> > more than fig-leaf protection.
> Wrong!  Python bytecode retains scopes, variable names, etc.
> Decompiled python code is really almost identical to original!
> About the only thing you lost are comments:
> http://sourceforge.net/projects/decompyle/
> http://www.crazy-compilers.com/decompyle/
> You can achieve a bit more protection by obfuscating names:
> http://pawsense.com/python..obfuscator/
> http://www.lysator.liu.se/~astrand/projects/pyobfuscate/
> but these only work on single-module projects and aren't 100% safe.
> At the very least, use python -OO to produce .pyo without docstrings.
> Note that -O also discards assert statements
> (lesson: never use assert for input validation in Python).
> Perl bytecode
> -----------------
> See:
> http://www.developertutorials.com/tutorials/cgi-perl/optimize-perl-050409/p
>age10.html http://perldoc.perl.org/B/Bytecode.html
> http://www.perlmonks.org/?node_id=62936
> (I never used any of those, just shooting relevant google results.)
> I don't know how much information Perl bytecode retains;
> from the little I know about Perl internals, I suspect it loses more
> details and does more transformations than Python,
> so decompiled code should looks less like the source.
> If even more armor is needed, there are obfuscators for Perl too.
> --
> Beni <cben at users.sf.net>
> _______________________________________________
> Python-il mailing list
> Python-il at hamakor.org.il
> http://hamakor.org.il/cgi-bin/mailman/listinfo/python-il

Shlomi Fish       http://www.shlomifish.org/
Parody on "The Fountainhead" - http://xrl.us/bjria

God gave us two eyes and ten fingers so we will type five times as much as we

More information about the Python-il mailing list