[Python-Dev] Open CPython VM for type information

[Brett Cannon]

On 12/12/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
>
> Dear Python developers,
>
> while the JVM is opened to support dynamically typed languages [1] I
> wonder if the CPyVM could not show more openness to statically typed
> languages? Hereby I don't think that much about arbitrary languages for
> the CPyVM but sublanguages like RPython which are "static enough" to be
> compilable into extension modules [2].
>
> However creating C extension modules from Python code is not really the
> standard way I do think Python source should be handled. Instead I think
> about a more direct VM support like the JVM does, that provides opcodes
> like iload, fstore etc. Besides this I don't expect one canonical
> approach for these type information to be feeded into the CPyVM. There
> are type inferencer like rtyper for PyPy, Psycos continous bytecode
> monitoring and also other approaches are possible that use type
> feedback. Finally optional type declarations are also an issue; however
> I would like to see language design discussions being separated ( ->
> Python 3000 ) and focus on general APIs for compiler extensions / plugs
> that deal with type information ( the architecture ) and VM
> implementation issues.
>
> Thanks, Kay
>
> [1] http://jcp.org/en/jsr/detail?id=292
> [2] http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html


The Python VM is not designed to be general-purpose, period.  Nor does
anyone on python-dev, to my knowledge, have any interest in putting the time
and energy into making it general.  I am quite happy with letting the Parrot
folk handle this goal.  This means that the maintenance cost of adding more
opcodes is not worth it.

But a bigger issue with me is the performance hit.  Every opcode will make
the eval loop larger.  And it is known that the eval loop is rather finicky
in terms of size and performance.  While no hard testing has been done, it
has been assumed we have accidentally hit the sweet spot in terms of CPU
cache size.

An important thing to keep in mind when comparing Python's VM to Java's is
that Java works (somewhat) for dynamic languages because people are
motivated enough to shoehorn languages into it by just assuming everything
is just an object and tossing out the type checking inherent to Java.  But
Java has not, to my knowledge, grown any great features yet to make dynamic
languages work better.  I know about JSR 292, but that is not in yet and
adding just one opcode is not that expensive to the JVM.  But compare the
cost of adding a slew of typed opcodes to Python compared to the JVM adding
just one is not really equal.

In other words, I wouldn't count on this ever happening.  =)  The best you
could do is try to propose some direct mechanism for adding support to the
eval loop to dispatch to some function for unrecognized opcodes, but I
wouldn't count on that being accepted either.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20061213/2e16ea85/attachment.htm