[Python-Dev] [ANN] VPython 0.1
cadr4u at gmail.com
Fri Oct 24 10:47:49 CEST 2008
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
More information about the Python-Dev