Python "byte code" description

[Michael Hudson]

Grant Edwards <grante at visi.com> writes:

> In article <7h38yz1kf1c.fsf at pc150.maths.bris.ac.uk>, Michael Hudson wrote:
> 
> > You can't.  But there are really very few tools that operate on
> > bytecode.  You can expect them to break with every major release of
> > Python.  I don't personally think that avoiding this is a worthwhile
> > pursuit.
> > 
> >> Or, what if I wanted to convert Python byte codes to JVM byte codes
> >> directly? Or Parrot byte codes? Or [insert VM here] byte codes?
> 
> IMO, a more interesting (from a geek/CS POV) project would be somebody who
> wants to write a compiler for a different language that generates bytecode
> that would be executed by they Python VM and inter-operate with "Python"
> bytecode.

OK, that's something I hadn't thought of.  Such a task doesn't sound
like fun, for a bunch of reasons.

> One of the big strengths of Python is the library.  If you
> generated Python bytecodes and used the same calling interface, then you
> could impliment a new language that could also take advantage of the
> existing libraries.

Yeah, but you can do that already through the C API, shurely?

[...]
> Perhaps somebody wants to impliment a hardware-assisted interpreter.  It's
> been done for JVM.  If PVM isn't defined/stable, then doing HW accelleration
> is going to be a bit difficult.

I think it's going to be pretty hard in all circumstances.  But you
make a valid point I hadn't thought of.

Cheers,
M.

-- 
  MGM will not get your whites whiter or your colors brighter.
  It will, however, sit there and look spiffy while sucking down
  a major honking wad of RAM.              -- http://www.xiph.org/mgm/