pyvm -- faster python

[Kay Schluehr]

Paul Rubin wrote:
> "Roger Binns" <rogerb at rogerbinns.com> writes:
> > Err, you proved my point!  Prothon was fine at the VM level.  The
> > author couldn't figure out how to get a decent sized "standard"
> > library, and ultimately ended up abandoning his VM for .Net since
> > that gets you a large standard library.  Jython also gets a large
> > standard library from the Java ones.
>
> What kind of stuff is in the existing Python C library that couldn't
> be reimplemented or retargeted pretty easily?  Most of it is either
> wrappers for standard C functions (system calls), stuff that
shouldn't
> be in C in the first place (the Python compiler and interpreter),
etc.

Delete the "standard" and You still obtain huge librarys for .Net, Java
and Python. I also regret that Prothon starved in infancy but it might
be exeggerated to demand that each language designer or one of his
apostels should manage a huge community that enjoys doing redundant
stuff like writing Tk-bindings, regexp-engines and all that.

> I hope that PyPy will replace CPython once it's solid enough.  Trying
> to stay backwards compatible with the legacy C API doesn't seem to me
> to be that important a goal.  Redoing the library may take more work
> than the Prothon guy was willing to do for Prothon, but PyPy has more
> community interest and maybe can attract more resources.

PyPy is a beast on it's own and provides interesting new ideas to
Python as well as runtime design in general. But I'm not quite shure
that it will stay in the boundarys of the current Python community
process and will subordinate to Guidos will. As a Marxist would say:
who controls the runtime also controls the language. Sooner or later
Python will go the LISP way of having a standardized "Common-Python" (
std_objectspace) and a number of dialects and DSLs running in their own
derived object spaces. Maybe Python 3000 is an illusion and will fade
away like a Fata Morgana the closer we seem come.

Kay