Self hosting Python? (was: Python is just as good as C++ for real apps)

[Gustavo Córdova Avila]

> 
> It's not hard to add unsafe operations to a safe language, and that
> lets you do your memory management (code generation, library loading,
> etc.) in the otherwise-safe language.
> 

Hmmm...

import Memory

p = Memory.BytePointer()

dict = { lotsa stuff }

# Assign to "p" the address in memory of dict.
p = dict

# now, let's examine the internal structure.
byte = p[0]

w = Memory.WordPointer()
l = Memory.LongPointer()

buffer = Memory.HeapAllocate(1024)
...
buffer.free()

etc... ???

> CMUCL does this, and as a result, when you want to hook CMUCL up to a
> new C library, you can write your glue code in Lisp instead of C.
> This is a really big advantage.  I wish I could do that in Python.

That sounds very, very nice.

Hmmm...

import Linker

ext_module = Linker.OpenLibrary("libKillerEncryption", version="1.2.3")

s = "blah blah a string"
es = ext_module.call_method("encrypt|s", s)

sounds... neat.

> > This all seems very reasonable to me. There is NO reason that an
> > application language should provide the constructs for modeling the
> > machine. Let's do the things that require such low-level notions in
> > C, including standard memory management and implementing numeric
> > packages. Removing it from the domain of applications is a boon.

But, besides making the language "safe", you remove some
functionality that can make the language truly "all-purpose".

Say, making a truly minimal python, which doesn't need
the standard C runtime. How about it?

Run the python interpreter directly over the linux kernel.
Reminds me of a C-128: basic running on top of the "kernel".

> I agree that applications normally shouldn't use those things, but you
> know, I'd just much rather write a Python compiler in Python than in
> C.

Definitely.

> An application language should provide the constructs its applications
> need to use.  An application language for numerical scientific
> computing applications should provide multidimensional rectangular
> homogeneous arrays.  An application language for compiling code on the
> fly should provide instructions and memory management.

And, if the code is dynamica, just like all the rest of python
during runtime, you can change it's semantics on the run;
sounds like a *very* dangerous, but fun, idea.

Hmmm... changing garbage collection, on the run. Or maybe the object
instantiation process... or installing a new thread handler...
or ...

I dunno, many of you have better ideas.

> > That said, it might be worthwhile to encapsulate the memory 
> > management (and other low-level mechanisms required) behind 
> > a fixed interface, implemented in C, and then make a Python 
> > compiler in Python.

Yup.

> Once you have the Python compiler, of course, the fixed interface can
> be implemented in Python instead of C.

Indeed. Eventually, Python removes all C code from itself, because
any code which needs to be emitted (machine code) will be translated
python code. No need for a C base, as anything can be compiled python.

This sounds like a great idea.

-gus