Compiler C or Python?

[Michael Hudson]

jhf at hex.no (Jørgen Hermanrud Fjeld) writes:

> On Tue, Sep 02, 2003 at 11:37:03AM +0000, Michael Hudson wrote:
> > jhf at hex.no (Jørgen Hermanrud Fjeld) writes:
> > > And in general, if should want to alter the Python compiler, should
> > > I start with the Python or C version?
> > 
> > Whichever's easiest :-)  This is usually the Python one.
> >
> Then I shall start with that one. Are there any other arguments/reasons to
> choose one or the other? That is technicalities one should consider.

I don't think so.  The code they produce is essentially identical,
AFAIK (the only difference I'm aware of is the ordering of the
constants in co_consts -- hardly critical).

Oh, Raymond Hettinger added some bytecode rewriting steps to the C
compiler in 2.3.  I don't think Lib/compiler does these.

For *very* simple tweaks I sometimes find Python/compile.c easier to
work with, but that's probably because Python/compile.c is a hunk of
procedural C code I've worked with a fair bit and Lib/compiler is an
OOP-y framework-y hunk of code I don't quite understand.  Someone
starting from scratch is unlikely to find this.

Obviously, Python/compile.c gets more testing, and probably has fewer
bugs.

> > > As far as I can see from your email the Python version is easier to
> > > modify, but why two compilers? Isn't that a lot to maintain?
> > 
> > The Lib/compiler/ package is pretty slow.  Also, making that the only
> > compiler might lead to irritating bootstrapping problems (which I now
> > see Jeff talked about...).
> Yes, but the code it generates will be fast enough for my purposes.

Oh yes, the compiled code runs at the same speed.

> Do you happen to know how consistency between the compilers is
> maintained?

Blood and toil :-/

Cheers,
mwh

-- 
  I have long since given up dealing with people who hold idiotic
  opinions as if they had arrived at them through thinking about
  them.                                 -- Erik Naggum, comp.lang.lisp