[Python-Dev] [ANN] VPython 0.1

[J. Sievers]

glyph at divmod.com writes:

> On 23 Oct, 10:42 pm, greg.ewing at canterbury.ac.nz wrote:
>>Guido van Rossum wrote:
>>>there already is something else called VPython
>>
>>Perhaps it could be called Fython (Python with a Forth-like VM)
>>or Thython (threaded-code Python).
>
> I feel like I've missed something important, but, why not just call it
> "Python"? ;-)
>
> It's a substantial patch, but from what I understand it's a huge
> performance improvement and completely compatible, both at the C API
> and Python source levels.
>
> Is there any reason this should be a separate project rather than just
> be rolled in to the core?  Obviously once issues like the 'Cell' macro
> are dealt with.

While it seems to work reliably, I don't think the current
implementation is really ``core-ready'' as it stands.
I consider it more of a prototype to demonstrate the potential impact
on these kinds of low-level dispatch optimizations (and for me
personally an opportunity to familiarize myself with the CPython VM).

IMO the main issues are:
 - Right now, CPython's bytecode is translated to direct threaded code
 lazily (when a code object is first evaluated). This would have to
 be merged into compile.c in some way plus some assorted minor changes.
 - The various things mentioned in TODO.
 - Finally, the core developers probably won't want to depend on Gforth
 (required to run Vmgen), so one might have to re-implement Vmgen (not
 a huge deal; I know that there are a number of unpublished versions of
 Vmgen floating around and IIRC one of them is even written in Python;
 even if not Vmgen isn't really that difficult to implement).
 Once that's done, however, I'd consider readability to have
 _increased_ if anything (compare the switch statement in vanilla
 Python 2.5.2's ceval.c to the patchset's ceval.vmg).

Note that none of the above are really show stoppers from a user's
point of view. It's about conforming to CPython's standards of
neatness.

Cheers,
-jakob